Technical debt occurs when a given architecture has to support new functionality and operate in unanticipated environments . As the architecture deteriorates the architect faces the following dilemma: rapid business response vs. technical debt.

Traditionally the options considered are: rapid business response at the sacrifice of architectural integrity – i.e. technical debt.

Scenario 1: Quick and Dirty. The architect finds some kludge that “tricks” the system to deliver the urgently required business value at the cost of architectural deterioration.
Scenario 2: Haste makes Waste. Take your time to design a robust architecture that supports the new required functionality, even at the price of delayed value delivery.

We propose a third scenario: On the Fly: Agile and Refactor design by doing. Under this scenario the new functionality set by business – Theme in Agile lingo is broken into smaller viable components – Epics and stories in Agile lingo – e.g. friendlier UX, more informative reports, more effective business flows. The agile architect introduces one of these epics by using a Kludge, sacrificing architectural integrity and entering technical debt. As the system runs the architect is able to assess various implications of the technical debt. E.g. excessive response time, excessive memory footprint, dramatically higher maintenance requirements. In the next phase, the architect fixes the most costly debt of the previous epic, i.e. refactors and aligns the architecture, while kludging in another epic. This “Firefighter” mode contains the most damaging aspects of the technical debt while still delivering rapid response. By only fighting the most damaging “fires” we achieve a “Pearl” action mode. Start with a quick-win, and later fix only the crucial problems.

Advertisements