Caveats of Solving Business Problems with Software

The handoff model of software development, where analysts understand the business and developers understand code, sounds clean in theory. Jesse Watson explains why it falls apart in practice.

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?

I've seen this pattern fail repeatedly: the belief that you can cleanly separate problem understanding from solution building. The reality is messier and more integrated.

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.

This gap between human intuition and computational precision is where most projects stumble. What feels obvious to a human, "just handle the edge cases", becomes dozens of micro-decisions that reshape the entire solution.

Watson nails the real work:

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.

The abstractions aren't just technical, they're conceptual bridges between business reality and computational possibility. Building these bridges requires living in both worlds simultaneously.