Programming Without a Safety Net

XP s primary safety net is, of course, unit testing (others include pair programming and collective ownership). With such safety nets in place (so the theory goes), it should be sufficient to cut out a lot of process that might otherwise be essential (such as sufficient design up-front and getting sign-off on detailed written specifications). But is this really a safe approach to software development? To put it another way: Should a team really be measuring success by the seat of their pants?

Picture a wartime night gunner who must keep a lookout from a small bunker on top of a remote hill somewhere. If he switches off his nighttime radar, he can save some serious battery power and therefore keep his soup- stove hot for the entire night. If his plan works, and he returns from his watch fully fed and flushed with victory, then this can be viewed as a success (and will probably be recorded as one in the sergeant-major s night-watch log book: No raids last night. Night gunner well fed. Another bleeding success! ). But if there happens to be a nighttime air raid during the well-fed gunner s vigil, he ll be none the wiser until a bomb drops inexplicably into his soup bowl.

The moral of this tale is that it s fine to cut corners and take risks (such as not specifying everything in a bulletproof, legally binding specification), as long as nothing goes wrong. People who do so will claim success. But when something does go wrong, you re in serious trouble. Even the unthinkable ”early termination of the project ”could happen. Looking ahead can be achieved simply by spending sufficient time on the design before you begin writing production code.

Although XP does include some practices that we should all put into use (in careful moderation ), the package as a whole leaves too many factors wide open to the forces of change (which is ironic given XP s embrace change motto).

Another analogy would be an American football team (we call it that in England) whose players have discovered that if they remove their helmets, they can run and dodge a bit faster. They might even win some games this way, but most of them will be too concussed to remember.

FANGS  

Fangs Gets His Eyes Tested

Test-first design (or Design After First Testing) focuses on code-level issues with the scope of a single test case or a small group of methods . Although it s not a bad practice, it s dangerous to rely on it as a replacement for up-front design.

Combined with refactoring and emergent design (covered in Chapters 9 and 12), the process represents a myopic approach to software design.

SOLUTION  

DAFT Defanged

Detailed up-front design modeling and test-first design can be used in conjunction. In fact (as we describe in Chapter 15), they re entirely complementary because they address different levels of design. Detailed up-front design is seen by XPers as a drawback because it delays progress. Our experience is that it saves potentially months of additional rework and redesign later. The following advice also sums up the benefits of detailed design:

During development, encourage developers to go to quite a detailed level in the design. They will hate you for it . . . initially. Well maybe at the end too! But, a few missed parameters can be a real headache . Ensure that your proverbial Channel Tunnel meets in the middle. ^[12]

It s important to balance this by doing up-front design in just enough detail, to recognize when you might be getting bogged down with analysis paralysis, and to use effective design techniques that provide a return on the time invested in them (rather than simply designing for the sake of it).

^[12] Antony Hirst, How to Make a Software Project Work, http://www.softwarereality.com/lifecycle/project_succeed.jsp, January 4, 2003.