About

My current view is simple: business software is mostly a way to automate real-world processes.

That means the core problem is rarely code first. The hard part is understanding the domain, naming things clearly, and arriving at a shared model of the problem with the people who actually know it.

I care most about:

• Strategic Domain-Driven Design to build shared understanding.
• Event Modeling to describe business processes and information flow.
• Vertical slices, acceptance tests, TDD, and pair programming to deliver working software.
• Fast feedback loops between stakeholders and engineers.
• Systems thinking when mapping software work to the broader system lifecycle.

In practice, I prefer a flow like this:

1. Understand the business problem with domain experts.
2. Model the process and the events.
3. Turn the model into acceptance criteria and implementation slices.
4. Build with tests.
5. Demo early, get feedback, update the model, and repeat.

If you want the longer version, start with How to deliver software efficiently.