O'Reilly logo

97 Things Every Software Architect Should Know by Richard Monson-Haefel

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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
image with no caption

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

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required