Borrowing From The Loan Shark

I am using the Template from "Antipatterns: Refactoring Software...." for this antipattern. I welcome discussion on this wiki from anyone who's ever faced this problem during a troubled project. -- ChrisFalter?@hotmail.com

Antipattern Name: Borrowing From The Loan Shark

Also Known As: Shortcut Through a Minefield

Most Frequent Scale: Enterprise

Refactored Solution Name: Quality Assurance

Refactored Solution Type: Process

Root Causes: Haste, Ignorance

Unbalanced Forces: Management of Complexity, Management of IT Resources

Anecdotal Evidence:

• "Why aren't you coding yet?"
• "Developer 'X' is too meticulous."
• "We have to move the code into production; we can't afford the time to change the design."

Background:

Loan sharks make their money by charging an exorbitant interest rate to borrowers who are desperate for cash but do not have the good credit to borrow from a more legitimate source (like a bank). At the time of the transaction, the borrower may think the deal is reasonable, but as time wears on, the 100% interest becomes difficult to support.

To understand this antipattern, you must also 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.

When management refuses to live within the constraints of the project management triangle, they may think that they have magically obtained something for nothing. What has really happened, though, is that they have borrowed from a 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.

General Form:

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. The second scenario under which managers borrow from the loan shark is when they refuse 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. In fact, though, when developers code under heavy pressure and testing schedules get shortened, code quality drops sharply. And when reduced-quality code ships, you pay for problems in production, including the costs of managing production crises, on top of the usury you must pay in order to debug and fix the code.

Symptoms and Consequences:

• 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.

Typical Causes:

• 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 managers and developers try to take shortcuts.
• Developers rush the delivery of code because they are interrupted to work on other projects and consequently have insufficient time.

Known Exceptions:

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 unmoveable deadline.

Refactored Solution:

It is possible both to prevent indebtedness and to repay it. In software projects we 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.

The way to remove the debt of poor quality code is by refactoring your code at every opportunity. While this applies during the maintenance phase, you can refactor a poor design during the test/stabilization phase, or even as part of the coding process. The earlier you refactor your code, the less you borrow from the loan shark.