97 Things Every Software Architect Should Know

Chapter 87. Pay Down Your Technical Debt

Burk Hufnagel has been creating positive user experiences since 1978 and is a lead software architect at LexisNexis.

—Burkhardt Hufnagel

ON ANY PROJECT THAT IS IN PRODUCTION (i.e., it has customers that are using it), there will come a time when a change must be made; either a bug needs fixing, or a new feature must be added. At that point there are two possible choices: you can take the time needed to "do it right," or you can take one or more "shortcuts" and try to get the change out the door sooner.

Generally, the business people (sales/marketing and customers) will want the change made as quickly as possible, while the developers and testers will be more interested in taking the time to properly design, implement, and test the change before delivering it to the customers.

As the project's architect, you'll have to decide which makes more sense and then convince the decision makers to take your advice; and, as with most architectural issues, there is a tradeoff involved. If you believe the system is reasonably stable, then it may make sense to go the "quick and dirty" route and get the change into production quickly. That's fine, but you need to know that in doing so your project is incurring some "technical debt" that must be repaid later. Repayment, in this case, means going back and making the change in the way you would have if you'd had ...