The Hidden Costs of Parallel Projects: Understanding Technical Debt
A constant problem for many companies is having too many projects to do compared to the number of developers available. That is why the whole prioritization process is so critical and so difficult. Too many business opportunities, too many priority-1 initiatives. What are the choices when faced with that?
A frequently chosen approach is to execute as many projects as possible in parallel to avoid “saying no” or because “it must be like that because it’s important.” That leads directly to the resource allocation challenge of determining what is the minimum number of developers that can work on the projects.
Let us imagine the extreme case of having 2 developers per project, just to assume those people will need code reviews and brainstorm on different topics during their journey. So that extreme situation goes in the direction of having the most projects in parallel but having them progress as slowly as possible (assuming the project could accept way more developers to split the work).
That looks like a purely legitimate management choice only impacting delivery dates. It really depends on the business priorities, market opportunities, etc.
But there are hidden emotional and technical side effects that come with that approach that are frequently overlooked.
The thing is, if there are so many initiatives to do at the same time, it typically comes with the desire to finish them as soon as possible to start the next one. Even if it is a conscious choice to reduce the velocity on a project to allow more projects to be executed simultaneously, that desire remains. The problem is that, week after week, that conscious initial acceptance of longer delays slowly dissipates while the desire to finish the projects as soon as possible remains. It starts to dissipate at the exact moment the people who made that initial decision begin to plan the next in-line project. It is classic: the closer the projects are to their final phase, the higher the desire to finish and to start something else.
At that precise moment, the criteria behind the initial acceptance of longer delays start to fall apart, even if the project is on schedule and budget (imagine if there are delays…). That pressure caused by all the other waiting top priorities can arise. Pressure itself is not a terrible thing; it can take many forms, some more unhealthy than others. The thing is, not everybody reacts the same way under pressure. In those moments, some people may diverge from the initial plan with the goal of reducing risk and assuring delivery dates. This is the typical moment when people start to be flexible in their values and start making compromises “for the business.”
This is the perfect moment to introduce technical debt. But not just any technical debt. No. A conscious one… justified by many good reasons, with a plan to resolve it later. If you are disciplined enough to fix it later, good for you. But those many good reasons justifying the introduction of technical debt are typically the same that justify the prioritization of new projects bringing direct money to the business over technical debt resolution, which brings indirect and less tangible benefits to the business.
And that behavior is not exclusive to non-technical people. Even the most talented and professional developers are included in that problem, especially when the internal reward system in place encourages developers to respect deadlines.
Another source of technical debt caused by many long ongoing projects is the fact that the business becomes less reactive. If all your task force is allocated for 8 months, what happens when there is an unplanned business opportunity or initiative that must be executed ASAP? Your hands are tied, with no room to be reactive. Sometimes the only solution is to pause an ongoing project and reallocate those resources to the new shiny thing. The problem is that during a project, it is frequent that some piece of the code or architecture is in an in-between/hybrid state. It is a normal code transition and transformation, especially if the project involves complex fundamental refactors.
That kind of state is dangerous if not taken care of properly. It adds complexity to the code, making maintenance more difficult. There are higher risks of introducing new bugs and higher risks of decreasing the velocity of the developers working on that code, etc. If a project has been deprioritized, chances are that it was the least important project. And chances are that it will again be deprioritized. The longer the temporary transition phase in the code lasts, the higher the occurrence of the risks mentioned above. It is even worse when new features are added on top of that transitional code.
How does doing fewer projects in parallel with more developers on them fix that? Why would less technical debt be introduced with that approach?
The question is good. And I do not have scientific facts to support that.
But it is something I have observed many times personally across quite a large sample of people, both technical and non-technical, over the last 15 years.
It is simply human behavior. The longer a project takes to finish, the higher the desire to complete it during the last phase. People are more tolerant of delays on short projects compared to long ones. People are also more flexible in their values when they get “tired” of something or when they feel pressure. In a purely ideal world, people should have the same convictions all year long. But we are not robots with predetermined behaviors.
So, keep that in mind: fewer initiatives in parallel, higher cohesion among people, shorter delivery times, and frequent wins really help people be in a healthier mood. And that helps in making better rational decisions during planning, analysis, design, and implementation phases. And I am not even getting into the path of discussing the increasing chances of dependencies or conflicts between teams/projects when there are many of them in parallel.
