The project triangle is a well known model to many, even the most junior of software developers know it.
According to the experience of the author of this post, almost all software projects end up behind schedule. And this is given that project managers are well versed in the significance of the triangle; the idea being that when things on one edge begin to degrade a trade-off needs to be made on the other edges to compensate. So when a project runs behind schedule the scope may have to reduced in order to stay on track.
However, the rendering of the model above is incomplete, it should really look something like this:
The above version of the is not nearly as popular as the initial one, especially since quality can be a very nebulous term to define for those working on software projects. However, it is widely known that when a schedule is tight, quality is the first thing to be sacrificed. This leads to there being a general understanding of what lack of quality looks like, even if defining quality itself can be difficult.
Lack of quality is present when simple features begin to take up huge work effort due to previously existing code that is either a miss or severely lacking in tests (amongst other signs of poor code quality).
In order to deal with this lack of quality that developers were consistently running into but unable to address, the term technical debt was coined. Technical debt was a clever way to ensure that everyone, even those without technical knowledge, could understand what happens when things are traded-off during a software project. All you need is an understanding of a basic financial concept: debt.
If you don't pay back your debt, it accumulates interest and becomes harder to pay off the longer you wait.
Despite the ingenuity of the technical debt metaphor, its benefits may be a little exaggerated.
If you look at how organizations are organized you will begin to see why the metaphor has limited benefits. When an idea is pitched it can eventually turn into a project with a dedicated budget and product manager. Once that project is completed the application becomes a part of the businesses portfolio and is seen as a product. At this point the product is handed over to a product owner who is, most often, not the same person as the project manager.
What ends up happening is that the project manager will incur debt, to get the project completed on time, only to pass it off to the product owner who has to pay it off. After this, the product owner may continue to incur debt in order to keep maintenance costs low and receive praise for this. They may end up being promoted from the product and the leaving the technical debt to the next person.
When organizations are dominated by silos, even if everyone understands technical debt, and its consequences, they may chose to ignore it and pass it off to someone else. If this is happening, then does it really matter that technical debt is so widely understood?
To read the full post visit here.