A pressing deadline is a powerful thing. Without a deadline, ideas can drown each other competing for supremacy in a sea of data. People use and abuse their own value functions to find fault with any possible approach. But faced with a deadline, thinkers break out of analysis paralysis and become doers. Of course, an unrealistic deadline just causes panic and sloppy work as people scramble to meet impossible goals and push themselves deep into technical debt.
I’ve long felt that iterative development (like Agile/Scrum) is worth exploring for just this reason. By forcing teams to march against regularly placed deadlines while empowering them to self-organize in the context of those deadlines, you harness the deadline’s power repeatedly during a project’s life.
I recently had a chat with a senior developer working on a very difficult task, trying to achieve demonstrable results in a tight time frame. I look at his workload and know he’s walking that fine line between “challenging” and “impossible.” How did he describe its impact on his motivation, his engagement? As the most fun he’d had at work in over 5 years. And what was the last one? Another crazy struggle, when a major scalability issue appeared late in a development cycle and teams were forced to come together and refactor major components with very little time to actually design and lots of pressure to actually produce.
Are software developers inherently broken, looking for painful exercises in futility? I don’t think so. I think if you look the tasks that push people to these heights of motivation you’ll find a few things in common:
- Well-defined success criteria
- Insufficient time to enter analysis paralysis
- Developers empowered to pursue their own ideas
- Cooperation of close-knit and competent peers
The question I can’t answer is whether people operating on those projects produce higher quality products. It’s clear to me that they enjoy their work more, but is that enough? Perhaps the ruthless attention to continuous integration you see at the heart of Agile/Scrum is a safety valve for that question.
