Deadlines and the Estimates that Make Them
(OR Why the Sleuthhounds Demo isn’t Ready)

January 30, 2015

Back in the halcyon days of December 2014 I blogged about releasing the first tech demo of my computer game, Sleuthhounds, in late January 2015. Well, here it is with just over one day left in January and I don’t think I’m going to make the deadline. BUT that provides the perfect opportunity to discuss deadlines (and start a sentence with “but”, which is generally a no-no).

Douglas Adams, of Hitchhiker’s Guide to the Galaxy fame, once said of deadlines, “I love deadlines. I love the whooshing noise they make as they go by.” And yet deadlines, I feel, are quite important to independent creative people. Especially to independent creative people trying to make a living off their creations.

There exists a certain heightened awareness of the days going by when it’s your own future and financial stability on the line. It’s a recognition that every day you spend creating something is another day that the something is not available out there in the world and so is another day the something is not “earning its keep,” so to speak, and helping to perpetuate the creative lifestyle. That’s where deadlines come in.

At its most basic, a deadline is a target date for completing a project. While an arbitrary date can be chosen this is a poor formula for sustained success, especially for software projects like the Sleuthhounds demo. Picking arbitrary dates will inevitably lead to the project running out of time. This results in one of two outcomes for software projects:

  • Critical functionality is missing and so the deadline MUST be moved to accommodate the critical functionality.
  • “Nice to have” functionality gets cut from scope resulting in software that is delivered on time but is less polished and has a poorer user experience for it. I suspect this is the reason why there’s a whole swath of mediocre software applications out there.

In theory, picking an arbitrary date could also mean that a project finishes earlier than expected. I can’t say I’ve ever seen this rare celestial occurrence on any project of sufficient complexity. This is because Parkinson’s Law dictates that “work expands so as to fill the time available for its completion.”

So if throwing darts at a calendar is not a good way of “choosing” deadlines then what is?

This brings us to the point of estimates. Estimates are used to make (hopefully) informed guesses on how long a project will take. Certainly you could estimate an entire project in one fell swoop—and for small projects of only a week or so that may be successful—but usually the more you can break down the components of a project the easier it is to estimate that project.

Breaking a project down also allows you to weigh the importance of different aspects of the project. You can more easily divide out the critical elements from the nice-to-haves. If you take it as given that all critical elements must be done, then you’re left with analyzing the nice-to-haves to determine if they’re worth the time it would take to implement them. It is here, among the nice-to-haves, that a software project will find the ability to adjust its deadline. However, that starts leading more into the area of project planning than estimation.

So, returning to our topic of estimation, what makes a good estimate? As I mentioned, an estimate is a hopefully informed guess on how long something will take. It’s that “informed” part that’s most important. If you’re not informed then you really are just guessing. You become informed by looking at other similar work you’ve done and how long it took to actually do that work.

To make this concrete, let’s take a real example based on my novel, Satin & Sutherland – The Golden Curse (yes, I know I’ve been talking software to this point, but writing is understandable to more people than the black voodoo arts of computer programming). From the planning stages of my novel and previous experience I expected the story to come in at around 110 – 130,000 words. I was a little light here as, ultimately, it hit 143,781 words.


Aside: Authors deal in word counts. Readers deal in page counts. Probably the most frequent question I get regarding my book is, “how many pages is it?” The reason authors deal in word counts is that the page count varies greatly based on the size of the page and the size of the fonts. That said, a rough estimate puts a typical paperback size page at about 275 words, so…carry the four…my book is roughly 520 pages. Huh. Didn’t think it was that long.


Several years ago I started participating in NaNoWriMo, the (inter)National Novel Writing Month. Each time I’ve participated in that event I’ve kept track of how long I spend writing. As a result of tracking that time, I know that I can compose a story at a rate of roughly 1000 words per hour. So, 130,000 words = 130 hours for a first draft. So how did I do?

I tracked my time writing the first draft of my Satin & Sutherland novel (as well as all the other aspects of novel creation). The first draft time came out to 145.5 hours, which is long for 130,000 words but pretty accurate for the final word count.

And that shows both the strength and weakness of estimating. The time estimate, based on the actual numbers, was quite accurate for the final word count, being less than 1% off. However, the estimate that was not correct here was the length of the book, being about 10% longer than I had first thought. Even so, basing my estimate on actual past performance gave a far better measure than picking dates at random. I only went two days longer than what I had planned.

The key to getting better at estimating, I believe, is in tracking past estimates and past actuals. If you go along estimating, estimating, estimating, but never compare against your actuals, you will never have a true sense of how accurate your estimating is. You may have a very rough idea of how long things take in your head, but that’s all it will be: very rough.

What all this means for the Sleuthhounds demo (you’d thought I’d forgotten about that, but I hadn’t) is that, yes, I did underestimate it. I’ve never created a full adventure game before so there are some unknowns and some of my programming/writing/drawing experience doesn’t fully translate into the adventure game domain. These aren’t excuses. They’re yet more illustrative points that estimates are just guesses, even if they are informed guesses. The actuals I’ve been tracking for the demo will help me to prepare a more accurate target date for the full game when it comes time to develop that.

At this point, the Sleuthhounds demo is looking to require another one to two weeks. It’s very near, just not here yet. In the meantime, you can begin speculating about how lead character, Pureluck Homes, got into the situation shown below (the second official Sleuthhounds screenshot, for those keeping score).

[Pureluck Homes imprisoned.]
Pureluck reflecting on his situation, NOT the quality of the game.
Click to view larger.

At the end of the day—or project, as the case may be—comparing actuals to estimates gives you more knowledge and more tools for more accurately estimating future projects. And that is good.