The idea of technical debt is a hot topic among software development groups. In particular, this concept shows up in agile efforts. While it is more a concept than a pattern, we can use this as a pattern for our design and development work. In fact, it lines up well with the Pareto principle and pushing details off until after delivery.
The Technical Debt Pattern Defined
I like to think of technical debt architecture as boxes and connections that are dotted lines. We sometimes see a whole section of functionality surrounded by a dotted line fence. These are referred to as future features or possibly optional. These items are, in fact, technical debt in the design. We are assuming they will be in that category before we even start on the solution. The pattern can be handled through phases of implementation or the amorphous “future version” label.
Applying The Pattern
This pattern is easy to apply. The designer or architect selects an item or items and designates them some form of future scope. In Agile terminology, this is an assignment to the backlog. The item(s) might even have some sort of special priority or designation to put them in a backlog that is pre-backlog in the process. The term hold or ice is not uncommon for these items and implies how little with think of the priority. While this approach can be a way to kick the can down the road, it is also a pattern for focusing on high-value features first. These have less value by definition and we will get to them once the more important features are complete.
