ASP.NET, SQL Server, WPF, C#, VB.NET

I once worked for a fellow named Joe at a bagel shop. Joe told the story of a bagel shop owner who had died as a result of falling into his dough mixer. "He had borrowed money from a shark," stated Joe, "and had trouble repaying the money. So it wasn't an accident; the shark got his goons to toss him into the machine as a warning to anyone else who might claim  not to have the means to repay."

Far too many software projects borrow from a metaphorical loan shark.  This happens so commonly that it would be reasonable to describe this phenomenon as an antipattern (essentially, a development practice with negative consequences).  To understand this antipattern, you must first understand the project management triangle. The basic principle of the triangle is that any project must balance the three forces of cost, time, and functionality. As one example of how the triangle works, if you want to increase functionality, you must either increase the time allotted for the project or increase the cost in terms of resources like analysts and programmers. Or if a project runs into trouble, you must extend the schedule, cut the functionality, or increase the costs (by hiring extra contractors, for example) in order to deliver it.

When management refuses to live within the constraints of the project management triangle, they may think at the conclusion of a project that they have magically obtained something for nothing. What has really happened, though, is that they have borrowed from the software project loan shark. The development shop will be paying usurious interest in the form of dramatically increased maintenance costs and more difficult revisions for a long time to come.

How Do We Get into This Mess?

This antipattern can actually occur in a couple of different ways. The first happens when management essentially plans from the outset to borrow from a loan shark by refusing to pay for quality assurance practices like a thoughtful design phase, code reviews, or thorough testing. Management knows that the quality may suffer, but they are convinced that the gains in the form of a lower budget or more expeditious schedule will more than offset any costs.

If you don't pay for quality, though, you pay a magnitude more for the lack of it. According to Steve McConnell, every hour spent on preventing defects by walkthroughs, code inspections and the like reduces the time spent on repairs by 3 to 10 hours. (Rapid  Development, p. 71) That means that if you don't pay up front for technical reviews, you are in fact borrowing from the software project loan shark at up to 900% interest!

The second way managers borrow from a loan shark is by refusing to cut functionality or lengthen the delivery schedule when a project is in trouble. By forcing developers and testers to work harder and longer, management may think that they are somehow escaping the constraints of the cost/time/functionality project management triangle. But in fact when developers code under heavy pressure and testing schedules get shortened, code quality drops sharply. And when low-quality code ships, you pay for problems in production, including the costs of managing production crises, on top of the 900% usury you must pay eventually in order to debug and fix the code.

How To Recognize the Trap

You know you have borrowed from the loan shark if any of these problems has occurred:

* An incomplete design leads to time-consuming difficulties in integration.

* Rushed code manifests numerous bugs in testing.

* Poorly tested code causes difficulties when deployed to users. 

* Production bugs are difficult to fix due to poorly documented, poorly designed code.

Why We Fall Into the Trap

* The project's executive sponsor is unable to obtain adequate funding for the project, so project management cannot afford to pay for quality assurance practices.

* Political pressures to deliver a fixed set of functionality in a fixed timeframe overrun the better judgment of the development team.

* Inexperienced or poorly trained project managers try to take shortcuts.

* Developers rush the delivery of code because they are interrupted to work on other projects and consequently have insufficient time.

A Caveat

Sometimes a due date cannot be moved and functionality cannot be reduced because of an external requirement. For example, medical claims processors must process 15 different EDI transactions no later than October 16, 2003 due to HIPAA rules. Smart claims processing companies would invest heavily in quality assurance practices and leave plenty of pad time in the project schedule in order to minimize the risk of missing the deadline. Nevertheless, developing software is not such an exact science that a project might not suffer a setback that threatens the whole endeavor. If this occurs, the claims processing company might be willing to pay the heavy costs of poor documentation, poor code quality, poor integration with other systems, etc., in order meet the unmovable deadline.

How To Avoid the Trap

It is possible both to prevent indebtedness and to repay it. Of course, an ounce of prevention is definitely worth a pound of cure when it comes to avoiding the loan shark, and in software projects you can prevent the indebtedness by investing in quality assurance processes. Design walkthroughs, code reviews, and early testing are important disciplines that improve the quality of software and shorten its delivery cycle. It has become something of a tradition in the world of software development to regard these practices as luxuries that only life-critical systems like space shuttle management software can afford. If you're smart, though, you'll ignore the tradition and plan for high quality design and code. Quality is the most reliable path to reduced costs and shorter delivery cycles--not to mention customer satisfaction and development team morale. 

If you're dealing with an executive sponsor who believes in shortcuts ("we've always been able to deliver software without code reviews"), buy a copy of McConnell's Rapid Development, commit pages 69 - 75 to memory, then quote the hard facts at your next planning meeting. And consider documenting some of the support costs of poor quality code already in production in order to build your case.

How To Escape the Trap

As I know from my personal finances, it is possible to repay a mountain of debt by a disciplined and smart approach. The way to remove the debt of poor quality code is by refactoring your code at every opportunity. Martin Fowler describes refactoring as 

the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.

- Refactoring, xvi.

So if a bug appears after your code has been released, don't be afraid to improve any inferior design that you may discover. While rewriting an entire module may be overly zealous for fixing a single bug, improving the design of a class or a related set of  functions should be within bounds. In addition, you would do well to track which modules have the most bugs. If you discover that a handful of modules are the source of most of the bugs (a typical occurrence), make a project of refactoring that set of modules--if not right away, then as the first stage of your next revision. Finally, you should try to perform refactoring as soon as possible in a project's lifecycle. If refactoring can help during maintenance, why not perform it earlier, during the stabilization phase or even as part of the coding process? The earlier you improve your design, the more successful and less costly your project will be.

Now that you know how to recognize the software project loan shark, make sure you do not do business with him!  Pick up a book from the short bibliography and learn how to improve the quality of your next software project.  And above all, discuss with your team how the specific methods you can use to improve your code quality in order to deliver better software, more quickly, at less expense.

Appendix: Suggested Reading (adapted from Steve McConnell's list in Rapid Development)

Robert Glass.  Building Quality Software.

Bill Hetzel.  The Complete Guide to Software Testing, 2d ed.

Daniel P. Freedman and Gerald M. Weinberg.  Handbook of Walkthroughs, Inspections and Technical Reviews, 3d Ed.

An independent consultant based in Charlotte, NC, Chris has spent over 8 years in software development, including 5 years as an Escalation Engineer and Application Development Consultant at Microsoft.   He is also the principal of his family's home school.  You can contact him at chrisfalter@hotmail.com.