Some people seem to think that by impressing a sense of sufficient urgency that the impossible can be made possible.
Let’s consider the hypothetical scenario where you’re at home, and you live a 30 minute drive from work when traffic is good. Today, traffic is not good.
Your boss calls you in a panic and says you have to be at work in 15 minutes. You tell him you’ll head out immediately but it’s really unlikely you’ll be there in less than 30.
Your boss tells you that you need to be at work in 15 minutes or the company will lose its most important client. You tell him you’re already on your way, but it’ll still be 30 minutes, even if you speed and weave through traffic.
Your boss tells you that you need to be at work in 15 minutes or the company will go under, and it will be all your fault. You’re upset, and angry, but you tell him there’s no way you can be there in time.
So you break several traffic laws and finally rush into work 25 minutes later, your boss blames you for failing to come to work on time and causing the demise of the company. And you’re silently plotting how to murder your boss without leaving any forensic evidence.
The entire scenario is absurd, of course, yet this is an all too common scenario of software development: The business owner sets a development schedule that’s laughably unrealistic, and when the development lead pushes back, the business owner behaves as if he believes he can make the project complete on schedule by imparting a sufficient sense of urgency to the development team.
It won’t work, of course; the dev team may, of course, work in panic mode for the duration of the project and try in futility to make the deadline, and then when they fail they will be so exhausted and burned out that they will be useless as developers for weeks afterwards, but that means the project fails and the company has a completely demoralized dev team that’s probably been updating their resumes.
Project owners need to listen to their development teams when they say that the project deadline is far too soon. Instead of trying to crack the whip, project owners need to work with the development lead and project manager to figure out the alternative. That alternative may be a reduced list of features, a revised deadline, the addition of resources, or some combination of the three.
But setting an arbitrary deadline and offering only urgency and consequences to the development team for failing to meet it, apart from violating the Fourth Rule of Development, can seriously damage the morale, and by extension the value and effectivenes, of the development team.