The triangle of project management is a well-known model, used through and through since ages.
I assume most software developers, even junior ones, are familiar with those:
- Time
- Cost
- Scope
As for my personal experience in the software industry, all projects have been behind schedule, with only a few exceptions for small projects (some man-months). The reason might probably because initial estimations were too low, either by accident or on purpose, but that is a subject best tackled in another post.
Now, Project Managers also have been taught about the Triangle of Project Management. The idea behind this figure is that when things start to go badly, in one or more of the edges, one has to make tradeoffs on the other(s) edge(s). For example, when the project runs behind schedule, scope might be reduced to keep it on track.
However, the above triangle is wrong - or at least incomplete. The real model should look like this:
This version of the model is rarely shown, plus quality is hard to define, hard to measure and doesn’t appear in most dashboards. In essence, when schedules run tight and/or costs start to over-burn, nobody cares about Quality anymore (if anyone did before). It’s a death march toward delivery here and now, and nothing should stand in the way.
I wrote it’s hard to define Quality. That’s true even for software engineers. Even widely accepted metrics such as code coverage are not meaningful. Lack of Quality however, is universally acknowledged by programmers: a seemingly simple feature takes ages to develop, because the existing code is a tangled mess, or there are no/not enough tests, or… (insert you favorite here).
Because software engineers are despite widespread rumors not only creative people but also communicative ones, they came up with the concept of technical debt:
Technical debt (also known as design debt or code debt) is "a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution".
Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes later on. Unaddressed technical debt increases software entropy.
That was a stroke of genius! Even people who were clueless about code, software development and software quality could understand finance fundamentals. If you get indebted to the Great Bank of Software, then you’ll have to repay your debt later… plus interest.
However, I’m afraid this idea has only marginal benefits compared to the previous situation, because of one very persistent trend, silos. Think about organizations work: when an idea forms, it gets translated into a project, with a dedicated budget. To steer the project is the Project Manager. Now, if the project succeeds (and yes, it happens), the application becomes part of the assets portfolio and is considered a product. It’s assigned a Product Owner, who in most cases is not the same person as the Project Manager. In layman’s terms, the Project Manager incurs the debt and ru(i)ns to the next project while the Product Owner has to pay the debt!
An "interesting" development is for the PO to continue to incur technical debt to lower maintenance costs in order and thus improve his career path, get promoted as fast as possible and pass the buck to the next poor sap in the line.
In this great age of silos of everything, projects, departments, information systems, budgets and of course responsibilities, even if everyone can understand technical debt, many choose not to care about it - and leave the next guy to handle the problem they created in the first place.
Of course it’s not specific to software, as political figures unfortunately prove every day…