Saturday, October 9, 2010

The Brick-Layer and the Doctor

There is a long-standing belief among the planners and architects of the software world that coding is like the work of a brick-layer. Misled, perhaps, by the fact that the elements of computer languages are few and identical, they model the writing of software as a simple, linear, step-by-step process where the same fundamental operations are repeated over and over again. Slap down some mortar, lay a brick, true up the edges, lather, rinse, repeat.

They could not be more wrong.

Why do I say that with such confidence?

Because anything which is actually simple, linear, and step-by-step gets automated. Not all at once, admittedly--it took us more than a decade to get from the first general-purpose electronic computer (ENIAC, 1946) to the first object-oriented programming language (Sketchpad, 1960).

Stop and think about that. From plugging and unplugging a large web of electrical cables to writing object-oriented just 14 years.

It is not possible for competent programmers to be brick-layers. Competent programmers stop after laying down a couple of rows of bricks, say "A machine could do this!" and proceed to write one that does.

What, then, is the role of a programmer?

The world presents us with a complex, ill-defined, fuzzy set of problems. Most of them overlap. Some of them have a common cause. Some of them look very much like other problems with completely different causes. Millions of dollars -- even lives -- hang in the balance.

Programmers are doctors. Businesspeople present us with a problem: "I want a billing system." "This old system is too slow and it keeps crashing when we try to run payroll." "Why can't it just work the way I want it to?!?" Our work starts with diagnosis, and continues through selecting an appropriate treatment, tracking our patient's progress to make sure they comply with it, and following up with additional treatments if the first one doesn't work.

Over the next couple of weeks, I'll be writing a series of articles based in this metaphor. My goal is to help programmers and managers alike break free from the misconception that programming is unskilled, repetitive labor, that programmers are interchangeable "resources", and that the best way to write good code is to follow strict recipes with rigor and precision.

The world needs more good code. I want to help you write it.

Next...Diagnosing Sick Code.