During his early days as a mentor to some of the junior programmers at Multiplitaxion Inc; one of them, who we shall call Fred, had an issue with me and my management style. His issue was that I wasn't pushing him to meet deadlines.
Mr. Fred believed that my not pressuring him really hard, like most other traditional managers had pushed him in the past, was bad management on my part.
He patiently explained to me that, instead of me making him estimate the duration for his tasks and then letting him have enough time to complete them with a quality implementation, he would really appreciate it if I could estimate how long his tasks should take and then give him a dead-line so that he would start working harder as the deadline approached.
For most other thick-skinned programmers who were getting projects rolled out successfully at Multiplitaxion Inc, deadlines weren't working out all that well. They seemed to like the idea of estimating their own tasks and working in a pragmatic non-panic environment.
I had discovered, early on in my career that the mounting pressure to ship based on a given artificial deadline encourages developers to program by co-incidence. As a developer, I had learnt the lesson the hard way, and had told myself that I would not push teams I work with to program by coincidence just to meet a deadline; specially artificial ones.
As I grew in my professional and personal life I started realizing that not imposing any deadline on people and empowering them with trust, makes them much more productive. Then I met Mr. Fred who had issues with the whole no-deadlines-we-trust-you-to-get-things-done way to running projects. Here was a guy telling him me that he desperately needed deadlines and he needed to be pressured so that he would do his work as I stood there and looked at him, completely confused.
Deadline Driven Development or DDD as some call it lovingly, isn't new in the world of software development and this wasn't the first time I was seeing it in action. During my early days as an young and budding developer, I had seen deadline-driven-development in the world of project managers where it was rampantly popular. Having said that however, this was the first time in my life when I was seeing a team member crave for it. This was indeed my first experience of seeing young and budding engineers infected with an otherwise managerial disease.
Tom DeMarco and Timothy Lister describe a real life story, of how managers and senior executives, like keeping their teams under constant pressure of deadlines, in their book Peopleware: Productive Projects and Teams:
|
During the past year, I did some consulting for a project that was proceeding so smoothly that the project manager knew she would deliver the product on schedule. She was summoned in front of the management committee and asked for a progress report. She said she could guarantee that her product would be ready by the deadline of March 1, exactly on time according to the original estimate. The upper managers chewed over that piece of unexpected good news and then called her in again the next day. Since she was on time for March 1, they explained, the deadline had been moved up to January 15. |
The story might seem extreme to a few of you dear reader, and even though moving the deadline ahead might seem a little dramatic for most management teams to do, consider this: how frequently has your management seen you ship comfortably on time and have thrown in a couple of extra features in the mix asking you to build the new features in the same timeframe. Maybe the deadline wasn't randomly moved ahead, but adding random features, just to keep the team on their toes, equates to the same thing.
Deadline driven development is an approach to software development where the management constantly and rampantly disrespects the iron triangle. At multiple organizations that I've seen or visited, I've personally heard of or participated in more than one project and utilization meetings where people being able to head home comfortably at 6:30 is cited as a bad example of resource utilization.
Most veterans understand and have mastered the art of balancing between aiming for perfection and shipping and these kick ass developers will ship as fast as they humanly can. At times they'll estimate stupidly, stumble like babies and miss deadlines. Then they'll get up, get better and ship successfully. Peopleware does a pretty good job at describing the paradox of success when it comes to deadlines:
|
How many times have you heard that some new technique is going to be used because it is the only chance to make the hard-and-fast deadline, and that if the deadline is missed, there will be hell to pay? The setup of the change has already made its outcome more than a little dubious. The kid-like willingness to throw ourselves into a potentially embarrassing endeavor is defeated by the potential for ridicule. Paradoxically, change only has a chance of succeeding if failure, at least a little bit of failure, is also okay. |
Every time there is a business push to ship faster I see countless managers, just take the email, forward it to their teams and push them harder; under the optimistic belief that if the team really pushed harder they might be able to pull of a magic trick.
If you're a manager, your job is not just to build a gantt-chart and then run behind your team collecting the status in terms of percentage complete. Business is expected to rush software development teams into it's own death-bed through continuous increase in velocity but and some point you need to take the crap upon yourself, cushion your team from it and let them function un-interrupted without the pressure of continuous and mostly artificial dead-lines. If you need to sit through a thousand meetings to convince the business, please do; if you must get into heated argument with marketing guys and your bosses please do; but if you pass of a stupid artificial deadline to your team all you do is demonstrate the lack of your management skills.
If you're a budding manager and the next time they tell you that there'll be hell to pay if a deadline is missed, try to investigate a little more into exactly how the business gets impacted and what is the actual loss involved if you were to miss a deadline for a few days. Chances are, there'll be none and there is invariable a high possibility that the so-called magical deadline which appeared out of nowhere would be the brainchild of a prick trying to push the team a little harder by pushing random deadlines.
I've been a part of multiple projects and have worked with a huge numbers of developers. I have hardly ever seen programmers cheat their organizations and have a fun time watching movies and playing video games when they had a clear sense of what they were expected to do and what the organization expected out of them. Working under the assumptions that your employees are out there to rob you and then pushing constant deadlines at them so that they don't miss-utilize their office time is outright stupidity which does nothing other than encourage the infinite loop of failure within the organization and the software development world in general.
Deadlines Driven Development is for a team of Dummies. For everyone else who is decently smart, there is communication, collaboration and successful implementations.
Comments are closed.