Don't “Design at the Keyboard!”

© by Mike Robinson

Maybe so, Frank. Maybe so...

Well, there must be something in the water, because throughout all my schooling one point was always pressed:   don't design at the keyboard! I took that advice, tried it, and found it to be true. Since in my college days we had to do everything on a timesharing system (the IBM PC had not yet been invented), this gave me a lot less trouble competing for “keypunch terminal time,” and a lot more time for, say, long walks. Or fishing. We've very-thankfully come a long way since “coding forms” were handed to the punched-card operators, but it seems to me that just as soon as we got rid of that antiquated equipment and gave programmers nice terminals to use, our programmers turned into Frank's Fish. They started jumping into the net of bad design.

Let's face it:   whenever we walk through a bookstore and see titles like The Programmer's Death-March, Death of the American Programmer, and the venerable Mythical Man-Month, now in its umpteenth edition, we know there's a serious problem and also that it's a chronic one. And I think I know what it is:

“Don't design at the keyboard.”

“Code later, ask questions first”

Programmers tend to get that quote backwards. As soon as they've been given the slightest description of what a new system is supposed to do, maybe their fingers start to itch. They want to be doing something, and that “something” is to write code. Suggest to them that it would be well worth their time to do some advance planning first, and they'll fix you with the same Stare that Frank reserves for All Non-Fishermen. “Writing code” is what makes them happy; what makes them feel like they're making progress; what makes them feel that they're moving the project forward. But is that really what's happening?

If you've got access to a snapshot of your company's source-code libraries, try running a file-content search looking for words like FIXME, TODO, and BUG, normally in upper-case. These are “the little notes” that programmers commonly leave for themselves. How many of those are in your code? How long have they been there?

If you use a source-code control system (and you do, don't you?!), this will give you a change-by-change description of exactly what each and every change consisted of. There are many metrics that you can easily glean from this information, even just by taking a cursory look-around, which are very insightful:

• Frequency of change:   How many times does the same programmer check-in a change to the same module, both during development and thereafter?
• Nature of changes made:   Do the changes continuously advance the size of the module, or are there substantial deletions and replacements of the code?
• Age of a “typical source-line&rdquo:   Once a particular source-line has been added to a module, how long does it remain unchanged in its then-present form?
• Degree of change:   A version-control system will keep track of each and every version of a module and can tell you the exact source-code differences between any two. Select an early revision of the module and compare it side-by-side to the most recent one. How many changes are there, and what is the nature of those changes?

Computers don't lie. This is an easy way to get factual information about exactly how well your software development process is working. I think that you'll find (beneath the “noise” caused by thhe occasinoal tpyo) that your developers are actually advancing the source-code in fits and starts, removing and replacing slightly more than half of the original code that they put in.

(Note that this metric is most-useful when programmers have their own development-machines in which they can test their software before checking it in to source-control. If the source-control system is the only way to get source-code “from point-A to point-B” for a test-run, your change-data will of course be much more “noisy,” showing the effect of a lot more dmub tpyos.)

Problem Reports and Test Results Don't Lie, Either:

Ask any programming team how far-along they are, and they'll give you one absolutely-stock answer: sixty percent. Don't bother to ask them why or how they know; the answer's just “sixty percent.” It's worth no more than the paper it's printed on. If the programmers have not taken the time to plot out their intended course in advance, it is obviously impossible for them to actually know their own progress. They're only giving you an answer “to shut you up.” (If you've approved a project that has no actual, measurable metrics, you may as well do just that.)

But if you do have executive authority over the project, there are things that you can do which will not only give you plenty of advance warnings of any coming train-wrecks, but which will also impose significant process-improvements:

• Insist upon testing, while coding:   Appoint a small “testing team,” apart from the “development team,” and assign them the task of testing the project's modules while development is still going on.
• Allow the teams to devise their own approach:   Having given two teams these seemingly-at-odds directives, and having applied your executive authority to stipulate what they must find a way to deliver, step back and allow them to figure out their own way to get it done. (Hint: the first thing they'll do is to go to your boss, so be sure that he or she is aware of your plan and will back you up.)
• Publish the test-results:   Within the workgroup's area in the cube-farm, post regularly a graph or log of some kind that shows the test-results as they are brought to you on a regular basis by the testing team. Devise it in such a way as to promote the behavior that you want, namely, a steadily high percentage of completed and meaningful tests.
• Don't publicly employ metrics that are easily-manipulated:   You can use explorations of the source-code control system “in the privacy of your own corner-office” to gauge how the programmers are actually doing, but don't publicize these results and don't make it widely-known that you are doing it. These metrics are too-easily manipulated just by changes in the programmer's behavior; changes that won't lead to an improvement in product quality.

Another strategy that you can use is to create a formal problem-reporting system, once again before software development is complete. When defective behavior is discovered, it must be typed-up and logged somewhere. When the problem has been corrected, the programmer must sign-off on it and the testing team must re-evaluate to be certain that it's gone. This doesn't have to be an onerous process, and it shouldn't be. But once again, the process imposes a greater awareness, not only of the notion of “defective behavior,” but also of the need to be able to specify in-advance what “correct behavior” actually is.

Formalizing the processes of Requirements Discovery and Change Management:

Every system built by man, whether it's a building or a sewer or a piece of computer software, does have a set of requirements that it must reliably fill in order for it to be said to be “correct,” “complete,” “acceptable,” and “useful.” In most disciplines, the requirements-discovery process is formalized and occurs in-advance. Students are trained from the very beginning of their education to expect and to follow this formalized process, either as participants in the discovery process themselves or as implementors who will expect to receive the product of this formalized design, i.e. a blueprint. It is unfortunately to our industry's great dis-credit that knowledge workers usually never encounter this, either in school (if they actually went to school to learn how to program) or thereafter. The programming industry appeals to the “lone wolf” and it champions the “lone wolf.” But a formalized requirements-discovery process, initiated before any coding-work begins and maintained throughout the project, invariably leads to better results.

Another useful technique we can glean from the construction trades is the notion of a change order. If the need for a change to the original plan is recognized after the work commences, the justification for the change and the nature of the change must be documented in a change-order. All such changes are carefully logged, becoming part of the permanent record of the project.

All buildings, all sewers, and all computer programs are complex systems, consisting of many separate functional units which all must behave properly together. It has long been recognized in the construction trades that the combined efforts of many teams, working closely together but in parallel, must come together at precisely the right time and place as the project moves toward completion. A timely change that is made on-paper before work begins costs almost nothing., whereas it is immediately obvious, and obviously costly, when mistakes are made in physical projects (such as “omitting all the electrical outlets in one wing of a new school”). Nevertheless, unless a formal requirements-discovery and change-management process has been put in place in a software project, errors that are even more outrageous than this might go unrecognized until the last possible moment.

The talent of the undisciplined “lone wolf” programmer is also his downfall. A skilled programmer can keep many things in his or her head at one time, but only about one or two programs at a time. The programmer's knowledge of a system is inherently in depth, not in breadth. And this is precisely what leads to the shortfalls and massive overruns:   if the team's course is plotted “from rock to rock,” discovering the full extent of the project (and its pitfalls) only as it goes along without the benefit of a formalized broad view, both the practitioners and the executives are flying blind. This is not acceptable, and executives must judiciously apply their authority to be sure it doesn't happen.

We all want to catch fish:

Ask a fisherman “why they do it,” and he might tell you that he does it for the sanctity of solitude with nature.

Fishermen are liars.

Despite the sanctity and solitude of nature, nothing beats the pleasure of coming back to the dock with a stringer full of the day's limit, displayed with a very-slight smirk to another fisherman who's wearing a not-so-slight scowl. Let's face it: we all want success, and none of us want failure. We want to deliver our projects to our customers to their very obvious delight, and we want to walk out of their offices with no fear that “the phone is going to ring in the middle of the night.”

As Frank puts it:   “to catch fish, you gotta go where the fish are. And to do that, you gotta know where the fish are before you set out.” I think that computer software projects are exactly like fishing in that respect:   if you don't know where you're going and what you intend to bring back to the dock come suppertime, you shouldn't go out on the lake. Luck, as they say, favors the well-prepared.

As an executive, you have weight that you can throw around as you please. But what you really want is fish, and you know that you can't go out and catch them all yourself. You have to somehow create a successful team of fishermen. People crave success, for obvious reasons, and they really want nothing more than to reliably have it. Success in this business takes teamwork, and teamwork requires a plan. “Fish are caught at the morning coffee-pot,” quoth Frank, “not in the boat.”

Stress the point that discipline brings results. If people don't believe in what you are telling them to do, of course “they'll follow orders” but they'll follow them only in a perfunctory way. Therefore, leverage their innate desire to come home with a stringer of fish and to be home every night in time for supper. Impose your changes, as you must, but do so lightly. Strive to create an improved work-environment in which the improvements that you seek simply “happen.” Let people discover the value for themselves, and let them devise their own improvements. Apply gentle pressure in the sense that you expect results, then teach them to fish.

People want to do a good job. They don't go out in their coding-boats to come back empty handed, even though they so often do. Talk about “grand methodologies” and “this is the way it must be” mean no more than the poutings of Willy Lohman in Death Of A Salesman. People want to succeed, even if they don't know the best way to do it. They'll substitute “effort,” and brute-force, and “dedication,” and still not catch fish. When you teach your staff a better process, letting them discover it for themselves by gently placing them in a position where they must, you're really “giving them their lives back,” and in time they'll appreciate you for it.

© Copyright 1996-2008 Sundial Services. All rights reserved. | Terms of Use; Copyright; Trademarks | Privacy Policy | Website Credits | Site last updated:   August 14, 2008.