One of my more perverse guilty pleasures in software development is deadlines. Deadlines take the task of developing software, which is usually pretty complex, and add a another dimension to it, which sort of makes me feel like I’m in game-show mode. I start to think about creative ways to cut corners, and I feel the rush of still being able to deliver against the odds. If it’s just me working on the project, I can let my hero syndrome flex its muscles, or if I’m on a team, it can feel a bit like a sport where you try to coordinate and deliver on the seemingly impossible. It takes a different type of creativity to be able to figure out where to cut the corners so that everything still works, and I enjoy those new types of challenges as well as the rush that comes from conquering them. I haven’t actually done any hackathons yet, but I imagine I’d enjoy them.
Deadlines have a lot of real plusses:
- The business knows to expect *something* at that time that resembles the original request. This makes the development process seem somewhat more reliable.
- The programmer gets a sense of clarity about his task when “doneness” can be defined with just a date, and some resemblance to the sliding requirements.
- The programmer gets a sense of urgency, and therefore feels motivated.
- The programmer doesn’t have to bother doing the hard work of learning to estimate properly, and doesn’t have to feel personally responsible for poor estimates.
I don’t mean that with any kind of sarcasm either. It may sound machiavellian to say things like “deadlines motivate programmers”, but the fact of the matter is that they do (they’re not the only way however — I’ll get to that later). In fact, the programmer himself can be the biggest proponent of deadlines, if he has only worked in deadline-driven environments. That type of programmer will in fact cling to deadlines, because for the aforementioned reasons (people really do want to feel motivated at work). Without them, he ends up drifting through the day, and not knowing when to stop working on a given task. He certainly has never learned to estimate properly, and is all-too-happy to never have to bother trying to push-back against management on unrealistic deadlines.
So there are real reasons why deadline-driven development is attractive to all people involved, and it should be no surprise that many software development shops just go from one deadline to the next in a fashion that can only be described as deadline-driven development. There are certain realities that exist for these shops though, regardless of whether they’re recognized:
- Most employees don’t want to work beyond their agreed-upon 8 hrs very often. A system that tries to run counter to this will have high employee turn-over, and therefore incur heavy employee on-boarding costs on a regular basis.
- Technical debt will be incurred constantly. This is a perilous practice that makes your development process slower over time until the team can no longer develop seemingly basic features in any sort of reasonable time. It’s dangerous because it’s very hard to even notice that it is happening until it’s too late.
These results create a feedback loop that only serves to amplify the problem: Employee turnover and on-boarding costs both increase as technical debt increases. Developers that are new to the codebase tend to create more technical debt as well. Because of this, the deadline-driven approach to software development can quickly spiral into dead-end codebases that are so mired in technical debt and complexity that no one wants to work on them, and they can’t be given new features easily.
Obviously I always go on and on about quality and how it’s the limiting factor in being as fast as possible, but there are some necessary trade-offs sometimes when you’re developing software in the business world.
For example, when I used to do freelance contract work, I would get a lot of contracts to create one-off microsites for companies that wanted to run online promotional contests. These microsites would need to go live on a not-too-far-away date where they would run for a few weeks before being closed down and deleted. I was still concerned about quality, because word-of-mouth is how I got contracts, but technical debt wasn’t any concern at all; I knew the software would just be deleted after a month, and I could do manually tested copy/paste spaghetti code to my heart’s content if it meant I’d be done faster. *
Also: If I was running a start-up, for instance, I would probably incur more technical debt than if I was working on software that was profitable and had hundreds of users. It makes more sense in the start-up scenario, because in that scenario, everything is a prototype — you’re not sure if the idea itself is even worthwhile. You don’t need to fight technical debt to ensure a fast future, because you need to be fast NOW, and you might not even have a future. (Don’t get me wrong though… I’d still do a heck of a lot of TDD and aim for high coverage so I don’t have to repeatedly test things manually, but then again I’ve got a lot of experience with automated testing, and I can write tests quickly enough now that it’s an obvious time-saving over manual testing.)
So there are certainly some times to willingly take on technical debt. There’s a great blog post by Steve McConnell on this.
The cold hard facts of the matter though are that if a start-up ends up being successful while taking on technical debt, that technical debt will cost them over time, regardless of whether they realize it or not, or whether they decide to do something about it or not. It should be obvious that on a long-lived codebase, a team is faster over-all when it minimizes technical debt at every step, rather than letting quality be the dimension that slides as a deadline approaches. Deadline-driven development is basically a way of borrowing against the future speed of development to meet a certain date. It is tempting because it almost always works over the short-term, but over the long term all the codebases I’ve seen that are continually developed this way grind the team to a virtual halt at some point.
The corollary to this is that over the long term, a team should theoretically be able to develop faster without deadlines. That will almost certainly seem like insanity to anyone that’s only done deadline-driven development, but in my experience it’s true; I’ve worked on such a team, and while it was extremely fast, it was also an easily sustainable pace where everyone was happy with the results.
What does it take to get there?
- Everyone needs to realize that deadlines almost always incur technical debt and that technical debt is a way of borrowing against future development speed.
- Developers need to learn a new definition of done so that their work has a clear point of completion and so that it includes making sure technical debt is not accidentally incurred.
- Developers need to learn how to estimate reliably against this new definition of done.
- Developers need to find a new source of urgency to stay motivated. (In reality though, meeting their own estimates is usually challenge enough!)
- Everyone needs to acknowledge that estimates come from the developers.
- Everyone needs to figure out how to keep management up to date on the real progress.
- For the most part, management needs to be content with monitoring the speed of progress rather than trying to dictate it.
I’m not trying to say these are easily attainable goals, but I do know that once you’ve attained them, the team moves very fast. I basically liken deadline-driven development to a rolling wheel that often stops or goes in reverse briefly compared to a wheel in a more quality-driven approach that may move forward more slowly, but never stops or rolls backward. In my experience the slower moving wheel that never rolls back has a faster net speed and is more reliable and manageable for the business.
* There’s a flip-side to that story too though… After 4 or 5 of those microsites I started to see a pattern in the requirements and started to build up some higher-quality libraries I could use to implement a new site easily to the extent that a site that would take me 3 days would later take me 3 hours.). You can be sure that I spent a lot of time making that library super DRY and well (unit) tested because that was code that had a future.