Monday, May 20, 2002

Came across this article from 1996 by Steve McConnell while researching Target's software development methodology. Amazing how relevant a six year old article can be, and how refreshing it is to see a big ol' company like Target focusing on delivering quality solutions by making sure they don't rush through either requirements gathering (analysis & design) and/or testing. Raise your hand if the following scenario sounds familiar: Projects that are rushed are particularly vulnerable to shortchanging quality assurance at the individual developer level. Any developer who has been pushed to ship a product quickly knows how much pressure there can be to cut corners because "we're only three weeks from shipping." For example, rather than writing a separate, completely clean printing module, you might piggyback printing onto the screen display module. You know that's a bad design, that it isn't extendible or maintainable, but you don't have time to do it right. You're being pressured to get the product done, so you feel compelled to take the shortcut. Two months later, the product still hasn't shipped, and those cut corners come back to haunt you. You find users are unhappy with printing, and the only way to satisfy their requests is to significantly extend the printing functionality. Unfortunately, in the two months since you piggybacked printing onto the screen display module, the printing and screen display functionality have become thoroughly intertwined. Redesigning printing and separating it from the screen display is now a tough, time-consuming, error-prone operation. The upshot is that a shortcut that was supposed to save time actually wasted it in the following ways: The original time spent designing and implementing the printing hack was completely wasted because most of that code will be thrown away. The time spent unit testing and debugging the printing hack code was also wasted. Additional time must be spent to strip the printing-specific code out of the display module. Additional testing and debugging time must be spent to ensure that the modified display code still works after the printing code has been stripped out. The new printing module, which should have been designed as an integral part of the system, has to be designed onto and around the existing system, which was not designed with it in mind. All this happens when the only necessary cost--if the right decision has been made at the right time--is to design and implement one version of the printing module. And you still have to do that anyway. This example is not uncommon. Up to four times the normal number of defects are reported for released products developed under "excessive schedule pressure" (Jones, 1994). Projects that are in schedule trouble often become obsessed with working harder rather than working smarter. Attention to quality is seen as a luxury. The result is that projects often work dumber, which gets them into even deeper schedule trouble. 3:41:45 PM

A parable, of sorts, courtesy of Mark Pilgrim, who found it somewhere else. Is it a toaster, or a sophisticated, feature-rich breakfast food cooker? 3:03:15 PM

Fortune offers up some required reading (courtesy of John Robb). He points directly to reason #9 (out of ten), called "The New Economy Death Spiral." Good stuff: Alan Greenspan has his own theory on failure. Testifying about Enron in February, he noted, "A firm is inherently fragile if its value-added emanates more from conceptual as distinct from physical assets.... Trust and reputation can vanish overnight. A factory cannot." The speed of some recent crackups would seem to confirm his thesis. The first domino falls when questions are raised, sometimes anonymously. Wrongdoing is suspected. Customers delay new orders. Rating agencies lower their debt ratings. Employees head for the exits. More customers defect. And voila, you have what former Enron CEO Jeff Skilling has called "a classic run on the bank." 2:37:35 PM