Unnecessary trade-offs are the root of all evil in software engineering. This article is about one of the most common sources of such unnecessary trade-offs: The unrealistic deadline of a partner team leading to exponential growth of technical debt throughout the organization.
In this scenario your team is building some kind of new feature requested by some other team (“CoolFeature Team”) who insists they need it by date Y so that they can ship their feature by later date X.
The failure mode I’ve seen happen time and time again, is that the following happens:
- You realize that the right way of building the new feature cannot be achieved by date Y and so you resort to some short-term hack to make it happen. You actually have your thing ready by date Y.
- However, as date Y arrives it becomes apparent that CoolFeature Team’s project has slipped their own deadline date X and they really don’t need you to be ready yet.
- Tragically you discover that you could have built the new feature the right way, without accruing major technical debt, if you had known when CoolFeature team really needed you to be ready. However, now it is too late to start over and have the right way of doing it ready by the new deadline and the hack remains in place.
This case is distinct from you setting unrealistic deadlines for yourself. Sure, that also sucks, but at least you are in control of the impact and can make choices that you deem locally correct. But with partner teams coming into the picture that are doing work based on such deadlines it is important to realize how such bad planning can snowball through the organization. In fact, it can multiply the negative impact in an exponential way: Each partner may in turn ask for changes down the stack proliferating the original unrealistic deadline further into the organization.
What can we do? #
This isn’t a post offering advice on how to avoid slipping deadlines of software projects. This will happen. In fact, the professional thing is to mitigate the impact of inevitable slippage rather than attempting to fully eliminate it.
What we can do is:
- Realize when our deadlines have follow-on impact beyond the immediate reach of our team such as partner teams reprioritizing work and potentially accruing technical debt.
- Really, really be honest to ourselves what a realistic finish date for a project is. We will make planning mistakes, but more often than not it would have been possible to anticipate that a deadline was never going to happen.
- Especially as a leader who might be using deadlines as a device to improve productivity, it is important to consider the “total cost of the deadline”, which may be bigger than what is immediately visible.
Summary #
Deadlines in software projects can be viral in that they force partner teams to reprioritize work and accrue technical debt. In large organizations or complex stacks these partner teams may in turn “infect” their partner teams to work towards the same deadline leading to exponential growth of technical debt. As professional engineers we must consider the total cost of our decisions. When we fan out our deadlines into the organization it is important to be honest to ourselves about realistic deadlines to minimize unnecessary technical debt at the time of delivery.
Published