Castles on the ground

From Chapter 2: The Mythical Man-Month

Excerpt
For the human makers of things, the incompletenesses (sic)and inconsistencies of our ideas become clear only during implementation. (page 15)

Brooks points out that since a programmer works with "thought stuff," and not physical things, there's a tendency to be optimistic¹ about the effort required to deliver code. Physical things constrain a creation and keep the creator honest. For example, "Lumber splits. Paint smears." In other words, you cannot create a house from playing cards, but you can build castles in the air.² Software can seemingly do anything that can be imagined. That's the risk. It's only in implementation that we can know what's truly possible.

From my perspective, Brooks is right as rain. It's only in the doing that the necessary discoveries occur. And since the activity happens in a government-sponsored, bureaucratic context, these discoveries are both technical and programmatic.³

Of course planning must be done in advance of the discoveries. If you had to make a plan, you would probably weight the following technical considerations:

• Skill of the available programmers
• Experience with the selected development tools
• Familiarity with the development and deployment platforms
• Familiarity with the application design
• Adaptability of the architecture
• Intelligibility of the code

However, if you want to build a castle on the ground, here's a few programmatic considerations to factor into the effort estimate:

• Mismatch of available funds and customer needs
• Delinquent or non-existent requirements
• Staff availability
• Onerous institutional processes obligations
• Meetings, meetings, and more meetings
• Funding and proposal cycles that inopportunely draw off the key staff
• Vacillating management support
• Staff shuffling when the institution is between large projects

During my stint in NASA, I needed to progressively increase the schedule allotment for programmatics. The programmatic tax on a key developer can be as high as 50%. In other words most of your best talent may be consumed supporting non-technical work. Ironic. But the programmatics are a real and consequential as the funding that supports the entire effort. Ignore the programmatics and you will underestimate. (Typically this cost must be hidden since it's "just part of the job." But I digress.)

Back to Brooks' assertion that the discovery is in the doing. Remember all this discovery is happening on the clock. Decisions are made on the fly. An unwitting decision may (and often does) impact a generation of developers. Recognizing what is and what isn't an important design consideration is the realm of talent.

I have been most fortunate to have worked with a few programmers with the vision to see when the obvious led to trouble. Hiring one of these folks requires luck. No amount of punctuation or letters after a name indicates talent. Over the years I came to believe that hiring practices restricted to grads, especially recent grads, made it nearly impossible to find the best talent.

Experience is the best teacher and the best antidote to naïve optimism.

¹I'm reminded of that old chestnut. What's the difference between an optimist and a pessimist? An optimist believes we live in the best of all possible worlds. A pessimist is sure of it.
²Another chestnut. What's the difference between a neurotic and a psychotic? A neurotic builds castles in the air. A psychotic lives in them.
³Programmatic refers to the activities required to obtain and keep government funding.