Why is writing business software so hard?
A series of essays about building business software: why it is so hard, and what we trade away when we try to make it easy.
On a project I was responsible for, adding one column to one screen took a senior developer two weeks and touched around forty files, in a codebase where nobody had cut a corner. The engineers were skilled and disciplined, they wrote tests and followed the architecture, and if you had audited the work against the practices our industry recommends, it would have passed.
Reflecting on this, and other software I have seen, I came to realise that good advice had been applied at the wrong scale: a level error. The first essay finds it in the class, where a module belonged. The rest follow the same mistake into the places it hides next: the class diagram where a module map belonged, the service call where a transaction belonged, the class-level unit test, the isolation level where the transaction's scope was the real problem, and the database schema. Essay seven is a departure: it asks what we lost when we gave up a vocabulary pitched at the business screen. Essays eight and nine follow the same mistake out of the code altogether: into the job titles we hand whole responsibilities to, and into a process we keep performing after its reasoning has gone. Essays ten and eleven return to the running system: the network hop where a process boundary belonged, and the scheduled job where an accountable business transaction belonged. Essay twelve turns to coding agents, and the prompt where a delegation belonged.
They are written to be read in order, and each ends with something you can try against a system you already have. Those practical tests have also been collected on one page if you would rather start by looking at your own code.
- 01Fifteen hundred classes and no visible shapeDoing everything right produced fifteen hundred classes, fifty packages, and a two-week change to add one column.
- 02Between deployment and dataWe have durable ways to draw where software runs and what it remembers, and only temporary ways to draw what happens in between.
- 03Drawing the transactionThe transaction is a design object we use constantly and almost never draw.
- 04Yeah, but does it work?We had effectively one hundred percent coverage and still could not demonstrate that the software did its job.
- 05Why does it only fail in production?Why transaction bugs look intermittent, and why hiding the transaction makes them harder to understand.
- 06Why does modularity stop at the database?If information hiding matters in code, why do we so often expose the entire relational representation underneath it?
- 07Why can't I build a simple business screen on my own any more?What did we trade away when rapid application development became web development?
- 08One role per userOne person can hold several roles. Software organisations turn job titles into boundaries around the work and then pay for the handovers.
- 09When Agile becomes processThe Agile practices that survive are the ones the surrounding organisation depends on. The ones that help a team adapt are the easiest to lose.
- 10The network we choseOne modern server can hold a business's systems of record, and much of what we treat as the unavoidable cost of running them is the cost of the network we put between them.
- 11Where did this value come from?A scheduled import or export changes business data as surely as a screen does, and it deserves the same transaction boundaries, history and accountability.
- 12The extremely smart internCoding agents get most of the way on their own. What remains is delegation: agree the outcome, let them work, demand evidence, and do not merge what you cannot explain.