The silver's all around you

This is a response to Peter Kretzman’s coherent and insightful blog post, “No silver bullets. Really!” You should go read that first. I’ll wait.

Peter’s post, in turn, is a response to the classic paper, “No Silver Bullet: Essence and Accidents of Software Engineering” by Fred Brooks, in which Brooks says that complexity in software development is essential, not accidental. You should read that too.

Now here’s what I think.

What management doesn’t get

The distinction between essential complexity and accidental complexity is the thing that senior non-IT management seems to have a lot of trouble grasping. Many other parts of business are complex for no good reason; you can often improve productivity and get better results by reducing complexity in manufacturing, finance, maintenance, governance, and the like. Those are frequently plagued by accidental complexity. “If only we standardized our contracts” indicates accidental complexity. So does “Can’t we outsource building security?” or “Let’s write international contracts in dollar amounts so we can ignore currency fluctuations.”

On the other hand, Brooks stated twenty-two years ago, most of the accidental complexity has long since been squeezed out of software development. Compilers basically work. Hardware is reliable. Versioning systems are plentiful and robust, and they fully support branch/merge techniques.  Integrated development environments include auto-completion (viz. Microsoft’s “IntelliSense”), syntax highlighting, and embedded documentation.

As a result, almost all of the time an ordinary software developer is working, she’s actually working with what’s left: the essential complexity of the problem at hand.

It’s like this

The moment you take the complexity out of software development, you’re not doing software development anymore.

It’s the same phenomenon that you see, at a lower level, within the software development team itself. “Why,” asks a manager, “when I see Benny working, he’s always struggling with some code that doesn’t work?” Well duh–when the code works, Benny is done! It sounds facile, but it’s true.

Few other job roles deal so exclusively, minute-by-minute, with stuff that doesn’t work until you figure it out. The nearest comparison might be people in repair and maintenance trades, but even they often get to do things that are understood but not yet finished. Have you seen a plumber at work? He might find the leak in ten minutes but take two hours to replace the joint because it’s in an inaccessible place.

To programmers, who deal in abstractions anyway, there is rarely an analog to the “inaccessible place.” To understand the solution is to be done.

Problem solving is the job

That’s why we always seem to be struggling with problems. That’s all there is, beginning to end.

Peter Kretzman ties it up with this thoughtful summary:

So, we all have our silver bullet, I suppose: mine, along with Brooks’, consists of maintaining balance, practicality, and a broad embracing of multiple approaches, rather than one panacea.

The silver’s all around you! Now go make some bullets.