Youth, Exuberance, and Passion

© by Mike Robinson

There are plenty of articles out there which state, quite matter-of-factly, that the only kind of person you should hire is someone who is “passionate” about their programming-work... the sort of iconoclast who can be relied-upon to “get into the zone” and stay there. But is this really what you should look for? We don't think so... in fact, we think it could be harmful.

Without intending to sound too cynical, I think that “such people” can be neatly summed-up in at least two ways:

They are somewhat under (probably, considerably under...) the age of twenty-nine.
They have no life apart from the computer.

What does this mean to you? It means: burnout. Sooner or later (and it may be “sooner” or it may be “later,” but it will be...) this person is going to look up from his video-screen and utter to himself these immortal words: “what the :=O am I doing here, and why does all this stuff matter so much?”

Bingo: burnout. And, it just happened on your ~~watch~~ payroll.

The Myth of “Money” ...

When you're walking through an airport terminal at eleven o'clock at night, you notice things ... like it or not. One of those “or not” things are the inevitable advertisements. I remember one which features a (leather helmeted...) football-player, and the caption, simply, is “Money.” The buy-line is that this particular player so out-performed everyone else that his financial backers had just one word for him: “Money.” The small-print goes on to argue that such-and-so financial company .. the buyers of the ad in question .. were also “money.”

The sum-total of the “superstar programmer” mentality is basically no different than this: that if you hire “just one Mozart” he will surpass “ten Antonio Salieri's.” The argument (however persuasive it may be) is that such programmers have an inherent ability that no one else can be taught to master ... and so, a side-bet placed with them will inevitably and always come in head-and-shoulders above anyone and everyone else.

I don't agree.

No... (sorry, Joel)... I don't.

And here is why.

What does “superior programming ability” really consist of, anyway? (And, do we really want to “need it?”)

Computer programming is a relatively simple task: you figure out what you want the computer to do, and then you write a series of step-by-step instructions that are sufficient to tell the computer exactly how to do it. Since the work is exacting, it requires a considerable amount of focus and concentration. All of this is well-known: it has been true (literally) since the days of punched cards.

The superior qualities that are ascribed to these much-sought-after “Mozart programmers” are therefore really these: the ability to focus, concentrate, and stay focused. These are the only skills that are really distinct from one programmer to another, assuming that any two of them had started on the same (unfamiliar-to-them) project at the same time. The programmer with the greater natural ability to “keep a bunch of things in his head at the same time” is the one that these pundits will be calling “Mozart.”

My number-one problem with this reasoning is that, sooner or sooner, any major software project is going to exceed the memory-bank capacity of any “Mozart.” Therefore, as long as the management of the project is such that it relies upon anyone's “personal memory-bank,” the project is going to continue to be unnecessarily constrained. Management will continue to have to search far-and-wide for “Mozarts,” just to keep the project afloat. This is not a solid long-term strategy.

“Off with their heads!”

Perhaps the Queen of Hearts had it right when she said, “off with their heads!” Perhaps the best all-around way to manage a software project of any size is to minimize the amount of detail that any one participant must keep “in their heads.” Both the details of how a piece of software works, and the details of what must be done to it at any particular time, are not something that you want to store “only between Mozart's ears.” No matter how gifted this-or-that person may be at arcane arts (such as computer programming or orchestral composition), any single person's “memory” or “focus” should not be a critical-path point for any project.

The upper-management term for this is: key man.

In wartime, snipers always go after the Generals first, because commanding-officers are the “key man” in any military organization. Command-and-control decisions are concentrated in those men, who (unless they are very diligent at spreading their knowledge downward) are irreplaceable. It is for this very reason that senior officers work through their subordinates, conveying to them both their orders and their plans and intentions.

We continuously see that this is not the case in software. Particularly in open-source projects, both the key information and the entire driving-force of the project is contained in a very small number of people. “Documentation,” if it ever existed at all, is usually little more than an out-of-date Doxygen printout. Defects in the software are diligently tracked, but for the most part the source-code changes that accompany the resolution of the defects do not include detailed explanations nor documentation updates. The same “key men” are responsible for the lion's share of those updates.

So we have a classic example of “the key-man problem.” Only a few people really understand or care-about the software. When (and if) they abandon the project, if for nothing more than lack of interest (or “having reached the age of thirty-two...”), the entire project often goes fallow, and sucessor efforts are likely-as-not to simply start over.

A much more sustainable project-management strategy is one that continuously seeks to eliminate the reliance upon the “key man.” Here are some of the ways that you can help do this:

Use automated documentation tools as a source of control-flow knowledge:: Open-source tools such as Doxygen can analyze the source-code of an entire application to produce a detailed graph of control and data flow within the application. While their usefulness as a source of documentation is, well, “dubious at best,” they can serve as an automated source of knowledge about control and data flow within the entire system. Their HTML outputs can be browsed directly, but Doxygen can also produce XML and/or Perl-module representations of the same information. This information can be further analyzed, programmatically. A growing library of tools exist to do just that; some open-source, some commercial.
Document “the Designer's Intent”:: “What were you thinking?” When I read a piece of software (most-certainly including my own!), that's what I really want to glean from what I've read: “what was the person who wrote this code, or crafted this patch, thinking when they wrote this?” If the writer left-behind enough of this contextual information, and took the time to express complete thoughts, then it will be vastly easier to determine how to fix the code or how to enhance it. These comments do not have to re-state what the software's own source code already tells me: in fact, such comments are “worse than useless.” A good piece of documentation is written from one human being to another, and it must be complete enough to be assimilated, as a complete and useful thought, based strictly upon its own content.
Prepare, and follow, explicit project plans:: As I have said before, computer software projects are no different than any other substantial human undertaking which involves keeping track of substantial amounts of detail. The most difficult part of any software modification is the act of determining what should be done, and the further along one gets in “actual writing of code,” the more expensive it becomes to change or re-do anything. The (considerable) amount of time spent in meticulous research and design is never wasted.
Use open meetings, and collaboration, to resist the concentration of knowledge into any one “key man”:: When you have one person on your team who is “obviously a star,” there's always a temptation to just keep giving that one person the ball. But if you do that, no one else on the team gets to play, and more importantly, no one else on the team learns how to play. A team can only be a team when everyone's contributing and when everyone's thinking. So, even when the prevailing wisdom seems to be, “oh, let's just let Jon do it,” this must not be the strategy that you continually adopt. The entire company needs the entire team.
Use software tools that can link source-code changes to reasons:: Don't just use bug-tracking software to track bugs: use it to track all forms of progress. Use it to track “the designer's intent” as well as a chronology. Select software that can directly link bug-reports to the change records that are being logged in to your source-code control system. This gives you a daily timeline of just how your source-code changed, when, by whom, and (most importantly...) why.
Treat a “key man” with respect, but not reliance:: Every person wants to do a good job, and to be respected and recognized for doing so. Your “key men” are obviously no-different in this regard. Discuss this issue openly and frankly with the various members of the team. It isn't a negative reflection upon anyone('s knowledge, talent, abilities, or importance to the company) to consider that the success of the project must never rely disproportionately upon any one of them.
Don't under-staff a project:: Everyone wants to save money. Of course we do. But a project that relies too much upon a too-small team is going to burn out that team, even as it leaves you with a too-limited set of management options. So, go ahead and staff each project with an adequate number of individuals, both junior and senior. Include individuals whose only appointed technical contribution will be “project management.”
Don't think that software projects really “play by different rules”:: No matter what any pundit may tell you, they don't. Software projects are just like any other major undertaking that involves a lot of people, a lot of detail, and a lot of time. No matter what anyone might tell you about the “wisdom” of making things up as you go along, such a (non-)strategy is never wise. Software projects are “chronically and typically mis-managed,” and in my opinion a great deal of the literature that's written from the “different rules, different game” mindset is little more than a cover-up for that fact.