Originally published on LinkedIn here
All software products face this choice. Martin Fowler explains it as follows
"You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place. Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt." - Martin Fowler (see here for the full article)
This is a decision that all product development companies live through everyday. This simplistic look at technical debt frames it exclusively as a strategic decision.
- Slow Good Design and the product gets released late and dies a premature death.
- Quick Bad Design and the product gets released on time, but it becomes costlier and longer to make changes and fix issues as time goes on and your customers curse you, your support staff curse you and finally the cost is so high the product dies.
As a side note Martin offers a mitigation to this scenario with Refactoring
- "The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job."
- "The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future."
Intentional Technical Debt is a strategic choice between Slow Good Design and Quick Bad Design. However, Unintentional Technical Debt is poor execution (Bad Design without the intent of gaining speed) and should be eliminated.
How to eliminate Unintentional Technical Debt
Eliminating bad design and code by junior programmers is a "no-brainer" and you would assume every organizations would have a system in place. I ask around and the only answer I get is "Code Review".
In my opinion Code Review comes with some problems.
- It ties up expensive "experienced" resources.
- You lose time because already written code has to be re-written.
My friend Charles and I started down a different path. We came up with a very light-weight design method that you can easily teach junior programmers called "Software Design Sutra".
If junior programmers use this, they will not introduce Unintentional Technical Debt which saves you time and money. Sometime back, I took over a product which was very buggy and not able to respond to customer needs. Hence customers were leaving. I got the team to use this technique. Over the next few months the product stablized and new versions addressing customer needs started getting released.
I recently gave a detailed introduction of the technique to a group of architects. They responded very positively to it. Luckily they recorded it and allowed me to put it up on YouTube.
The presentation is available here if you have trouble reading it in the video
Let me know your thoughts.