The greatest misconception about software development is that it is a separable discipline from deep analysis of the business problem. We think all we need is an analyst who understands the business problem, a developer who knows how to code, then they can email a few notes or a specification. “Good to go”, right?
Not so much. At the outset, a business problem might appear simple, or only somewhat complex. You might think you have a handle on all the caveats and corner cases. But the average person who hasn’t programmed extensively doesn’t appreciate the level of detail and explicitness that computers require to do absolutely anything. Every behavior must be dictated with excruciating specificity. And your plan for how users will interact with the system will likely get thrown out and redrawn from scratch dozens of times before you have a minimum viable product.
[…]
Most of the time is spent thinking and communicating about a virtually endless number of micro-problems that seemingly emerge out of nowhere, and constitute the real territory between the technology and the business problem. Part of traversing this landscape of micro-problems is inventing, communicating, and internalizing a plethora of named and unnamed abstractions. It is the only way to break down the complexity so you can grapple with it.