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.

Challenges

Anytime we put an item on a backlog there is the danger it will never get brought back to be done.  Therefore, technical debt is almost an anti-pattern as well.  It can be a mechanism for sweeping features under the proverbial rug.  There must be ownership of these items and a push to ensure they do eventually bubble back up to be addressed.  That can require a strong product owner or project manager.  Nevertheless, it is possible and can provide working software for customers in a much shorter timeline.

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a lifetime learner as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences and a few about becoming a better developer. In his free time, he stays busy raising five children (although they have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax or working on his ballroom dance skills.

Leave a Reply