Timeless Truths Of Software Development

Having been a software engineering manager for literally decades, a few truisms have become evident. These have emerged in interactions with other roles, notably clueless executives or, worse yet, folks who came into software management from some other discipline such mechanical or civil engineering. Or, heaven forbid, marketing or human resources.

Yes, software is different. In fact, nearly all software is unique in that the particular capabilities being developed have either (1) never been done before; or, (2) if not unique, are someone else's trade secrets and unavailable. Consequently, nearly all software requires more than a modicum of exploration and experimentation, of trial and error, of continual refinement and understanding.

Of course, convergence on workable code is accelerated by wisdom, experience, skill, and raw native intelligence. Nonetheless, it is not the same as looking up the load of a bridge pier in a book, or calculating frictional forces in a gear assembly. Such tasks have occurred untold thousands of times in the past. When someone says "I need a bridge from here to there" the intent is understandable. With software, the intent tends to be vague, open to interpretation, and time and time again there's "only one more thing" . . . .

Software, in contrast, is new, typically from the ground up. Moreover, the underpinnings of the software -- computational capabilities -- continue to advance in accord with Moore's Law, with no practical end in sight. This evolution in turn continually renders older software obsolete. Even if the software continues to exist, there in fact may be no machine to run it. Or if it could be made to run, the performance would be unacceptable given how everything else is likewise evolving. And this is to say nothing yet about security, wherein exploits continually require software patches or new applications and devices for protection, requiring the continual creation of yet more software that has never been done before.

These facts, blindingly obvious to everyone who has written code for a living, seem to elude certain allied roles. There are those clueless (sometimes brainless) people who demand a plan for software akin to a plan for a bridge or a printed circuit board. It would be nice were it possible, but it isn't aside from the trivial case. The journey from inspiration to working code is subtle, unique, arcane, and highly dependent on the brainage and personalities of the developers. The requirements keep changing; the hardware keeps changing; the security environment keeps changing. Obsolescence begins when the software (or it design) becomes frozen. Dylan said it better: Proves to warn that he not busy being born is busy dying. Here are several observations that continually recur, written in absolute form to be provocative.

People Who Don't Know How To Do Things Always Claim They're Easy To Do

Yes, Alexander Pope was right: A little learning is a dangerous thing; drink deep, or taste not the Pierian spring: there shallow draughts intoxicate the brain, and drinking largely sobers us again. Effective software development requires intricate algorithms and sophisticated coding practices, refined skills and the insight of experience, all brought together with social finesse. Those in allied roles who have a smattering of learning about software and its development often press their claims (e.g., "build this", "don't waste time on testing", etc.) by expressing how easy such a feature would be to build. Naturally, they have a friend, or so they say, who could do it in a day. Worse yet, is hearing them claim that were the developers to build it right testing wouldn't be needed. Of course, the inherent complexity of interactions amongst software modules in any application necessitate testing, especially to protect against the clown-code that "just one more thing" adds. There comes a point of foregoing arguing with others about the false perception of ease; instead recognizing the individual's basic lack of understanding of the circumstances at hand. Out of politeness, co-workers typically don't draw attention to this intellectual handicap when it becomes evident. The one truism that emerges from this is that such people who claim such things are easy, rarely -- if ever -- can do it themselves at all.

People Who Don't Have To Do Things Always Claim They're Quick To Do

Computers are magic to those who don't write code. I've noticed that those people who focus on schedules are rarely the people who actually have to produce the work. Closer inspection reveals they often they don't even know how the work actually gets done, let alone how to organize it. The vagaries of dependencies elude them; the complexity of software development is beyond their ken, the orneriness of tools and fragility of build systems and constraints of legacy code are outside their experience. Often, their day to day work is relatively simple, not requiring the daunting learning curve of application development. Hence, all these myriad things that cost time elude their understanding. The detours while developing software are natural to the task itself. To naively expect such detours won't occur is to mistake their conception of the destination for the duration of the journey to get there. Software takes as long as it takes. It could always use more work. To paraphrase the poet Paul Valery, software is never finished, only abandoned. Not understanding where the time goes, doesn't mean it doesn't go somewhere nor that detours could've been avoided.

People Who Don't Have To Decide Things Always Claim They Know What To Do

Software development is tricky involving many partially-useful ideas, numerous alternate algorithms, myriad approaches to coding, and a maelstrom of personalities. The skills of being a technical manager are distinct from those of being a people manager. The activities of tactics are distinct from the perspectives of strategy. It's easy, and myopic, for an observer equipped with only a smattering of facts from one of these skills to foresee a simple solution to the situation at hand. Those with wisdom of people and organizations don't necessarily have technical insight. Those with technical brilliance may be inept at working with others. Tactics can be blind, but strategy in itself doesn't get anything done. A decision's quality is constrained by the domains of its considerations. If it only sees technical situations, people problems create bedlam. If it only focuses on people, redo after redo from technical blunders are commonplace. In all of these situations, those with one or another myopic, selectively informed point of view, claim they know just what to do. As H.L. Mencken observed: There is always an easy solution every human problem -- neat, plausable, and wrong. Making a decision brings with it the responsibility to use all the facts at hand, to draw on wisdom from all available domains, and to do the right thing for all the people involved. Not having to weigh such competing notions and make unpleasant tradeoffs is easily avoided by those who don't have to make the decisions.

Decisions are hard. Software is hard. When others claim it's easy to do, think about it. When they claim something is quick to do, give it some thought. When those not responsible to make decisions claim they know what to do, think it through. What unanticipated consequences can you see right away?

Software development requires deep skill to understand, let alone to perform. A software development organization is a complex social situation of many specialties, diverse personalities, clashing agendas, and demanding exactitude. Those who can actually deliver software don't make claims such as those above.

(CC) Some Rights Reserved.