How to deliver software efficiently.

A brief post that deciphers my new LinkedIn cover image.

1. What is software?

In my opinion, software is just a way to automate a real-life process (in most cases).

Let’s take a parking lot as an example:

• Driver drives his car to the parking lot entrance;
• Driver gets an entry ticket;
• Driver pays for the parking time;
• Driver gives the paid ticket;
• Driver leaves.

In the past, before computers, you’d still have a parking lot. The whole process would be done with human interaction: a person controls the entrance, fee collection, etc. Such parking lots can still be found around the world.

The most modern versions (I have not seen them in Germany, only in Kazakhstan 🤭) work as follows:

• Driver drives his car to the parking lot entrance;
• A camera scans the number plate, driver can drive in;
• Driver pays for the parking time in an app (apps like Halyk or Kaspi in Kazakhstan);
• Camera scans the number plate, verifies the payment;
• Driver leaves.

With no human involved anymore, one instead has:

• A camera;
• automated gates;
• probably an ML-algorithm that reads the number plate;
• a software server that coordinates the AI, the API;
• a banking app with a payment option.

But the process is still exactly the same.

In my opinion, software is just a way to automate already existing processes.

How to solve business problems with software

Now, to automate a process, one needs to understand it and document it.

And that’s the main problem -> I don’t often meet companies or clients who have their processes written down and thoroughly documented.

Even worse, I remember people who wanted “an App” but had no understanding of the problem they were trying to solve.

Disclaimer

I am not talking about infrastructure or low-level software in this article: networking, drivers, OS, etc. I have not worked in this domain, so please refrain from comments on that. If you work in it and want to share your experience -> please leave your comments :)

Enter Strategic Domain Driven Design

Strategic Domain Driven Design is all about arriving at a shared understanding of a business problem: customers, PMs, “the management”, and engineers all understand the problem, document domain-specific language (ubiquitous language), and model a solution (with tools like #EventStorming, #DomainStorytelling, or #EventModeling).

Sit down in a room with domain experts (people who understand the problem), draw diagrams / do “sticky notes”, arrive at a common understanding, and model a solution.

A good approach to doing it is Event Modeling.

I have not explored it, but it could be combined well with Domain Storytelling first -> then Event Modeling.

Common model

Once an Event Model is created by BOTH - customers/PMs/domain experts and engineers/architects - everybody understands the problem and is aligned on a solution.

• An Event Model is a visual representation of a business process and its information flow.

• It can nowadays be turned into a specification artifact (JSON/YAML) file, thanks to tools from people like Golo Roden, Martin Lorenz, Martin Dilger, Adam Dymitruk, Einar Ingebrigtsen, and Alexander Miertsch;

  • If I forgot to mention someone, I apologize. DM me, and I am happy to add you to the mentions here :)

And once all parties understand the problem and have agreed on a model of a solution, an implementation phase can start.

Extreme programming

One of the best ways to deliver working software is good old (early ’90s) Extreme Programming:

• Aligned with Customer (Event Model);
• Write acceptance tests (Given When Thens, based on vertical slices from the Event Model);
• In parallel, write the implementation using Test-Driven-Development and pair programming;
• Once the solution is ready, run it against the acceptance tests and, ideally, it shall work;
• Demonstrate it to a customer, get feedback;

During #EventModelingConference2026, I saw people just giving the Event Model spec to an LLM (Claude / Local Models) and, some minutes later, having working, production-grade software.

Systems engineering view

The systems development lifecycle from Systems Engineering defines the following steps:

• Concept;
• Requirements analysis;
• Design;
• Construction;
• Acceptance;
• Deployment;
• Maintenance;
• Decommission.

With Event Modeling and #EventSourcing, one gets:

• Concept;
  • The brainstorming stage of Event Modeling OR a Domain Storytelling workshop, essentially to identify:
    • the mission of the system;
    • stakeholder requirements;
• Requirements analysis;
  • Deeper Event Modeling work to identify:
    • system and subsystem requirements;
    • compliance requirements (system constraints).
• Design;
  • A completed Event Model that passes the information completeness check.
• Construction;
  • Software engineers / LLMs work on the software.
• Acceptance;
  • QA checks the solution against the spec from Event Model;
• Deployment;
  • Deploy to production;
• Maintenance;
  • Bug-fixing, new feature development (add a new “vertical slice” to the Event Model, then write and deploy it).
    • Maintaining a system written with Event Sourcing is easier than maintaining a CRUD-based system.
• Decommission.
  • Delete vertical slices from the code and the model (they are ideally decoupled, so can be easily deleted).

Software maintenance (Operation)

Demonstrate software to stakeholders -> get their feedback -> update the Event Model -> update the software -> deploy -> rinse and repeat.

And that’s all there is to developing business software.

But why is it complex?

Well, because the hardest thing when developing software solutions is still a biomass between a computer screen and a chair (Homo Sapiens).

Maybe one day Claude turns us into human batteries and locks us in the early 2000s, thus resolving the problem, but that’s for AI corporations to decide xD.

Conclusion

In the article I gave a high-level overview of what I consider a rather efficient way to develop software systems.

If you need to develop hardware -> you need to use Systems Engineering, which is a much heavier process than the one described in the article, although the structure is the same -> it’s the Systems Development Lifecycle.

Please share your opinions, thoughts, and experiences.

• But please be civil ;)