Deadline-Driven Development

May 29, 2013

Deadlines. We’ve all run into them. We might be talking about a project at work or filing our taxes each year. But deadlines usually get a bad rap. Everyone loves to complain about deadlines. But I like them.

What? Why in the world would I like deadlines?

Because they help remind me to ask questions. How?

Any time someone hands me a deadline, one of my immediate responses is “Why did you pick that date?” and “What does that date mean?”. Knowing what is driving the deadline and knowing what the person intends can be even more important than knowing the date itself.

Sometimes this is quite simple. Taxes are due on April 15th (usually) because that is what the government says. There’s no real room for discussion there (nor any real need on my part to know why they picked that date).

Other times, the reason for the deadline is worth doing a bit of digging to unearth. Maybe the deadline was selected because the client needs to show to their stakeholders in a certain calendar time frame. Maybe the date was picked because it is when the bigger picture is planned to come together. Or maybe a client relies on this piece of work being done in order to start on the next part of the process.

Example 1

  • Client: The deadline is date X.
  • Me: What does that deadline mean?
  • Client: It is when we need to have all our internal processes complete in regards to this project. Oh, and our internal processes take a month to complete after you hand things over to us.
  • Two things uncovered in this case: we now have a more correct understanding of when the client expects our part to be completed (a month before X). And we’ve also identified a possible risk that they might not have considered (that their internal process may take longer than a month). That probably deserves delving into a bit more before we finalize what date we plan to hand things over to the client.

Example 2

  • Client: The deadline is date X.
  • Me: Why?
  • Client: Because that is when the hardware will be ready to put the software onto it (or because that is when the other system that we’ll be talking to is going to be ready).
  • Again we’ve turned up some new information: the hardware (or other software) that our piece will be integrating with is not yet done. There are definitely some risks that there will be differences between the defined interfaces and what is produced at the end. Also, this leads to asking some questions about whether we’ll be getting pre-releases to let us test our implementation early, or whether it might be appropriate to develop a simulator for us to test our code against.

Remeber, any time you’re given a deadline, ask what is driving it. It can help make sure that you’re on the same page, and will likely give you some useful information that you might have otherwise missed.