Your project will take longer than you think and less than a Nukem

• Tweet

• Tweet

I will tell you how long your next project will take to release. You won’t like it, but I’ll tell you. A game is launching this week and in the story of its development is the key to successful software estimation. The game is Duke Nukem Forever, and just like the title, it did pretty much take forever to launch. Five thousand, one hundred and sixty days to be precise. That’s just over 14 years. Longer than it took to build the Empire State Building, the Golden Gate Bridge and the World Trade Center combined. It took so long, people have put up sites covering how long it took. The game is by most accounts at best mediocre and at worst atrocious—in my highly opinionated view, the duration of a release is inversely proportional to product quality. But that’s not the story here. What’s important is why it happened and what it can tell you about software estimation on your own project.

Duke Nukem Forever Launched after 14 years development; what can this big chested antihero teach you about your project?

Why it overran

There are a number of reasons why the Duke took so long to get his politically incorrect ass back out in the wild. As an adoring public were salivating at the thought of a new Nukem, the development team and its management were stuck in a pattern of events that pretty much ensured a death march of a project:

Scope Creep

Anyone who has ever been on a development project will be familiar with this problem. After the success of Duke Nukem 3D, George Broussard—the game’s creator—kept seeing opportunities for ever more awesome features to put in the experience:

Broussard simply couldn’t tolerate the idea of Duke Nukem Forever coming out with anything other than the latest and greatest technology and awe-inspiring gameplay. He didn’t just want it to be good. It had to surpass every other game that had ever existed, the same way the original Duke Nukem 3D had.

Snow scenes? You got it. Online Multiplayer? Of course! These sorts of things may seem price-of-admission now, but bear in mind that these features were being added over ten years ago. And – I’m not saying that these were bad ideas or unnecessary ideas, just that the goalposts kept moving, which makes it kind of tough to finish.

Technology Death Spiral

When Duke Nukem 3D came out, it was built on a game engine named “build” by a child prodigy called Ken Silverman. In order to keep up with ever increasing needs of the project (see above), Broussard swapped out for a new game engine not once, but twice. This, again, may have been necessary, but it meant that the development team were always playing catch up.

Too much cash, not enough business

Here’s the thing: Duke Nukem 3D was a runaway success. So much so, that unlike before, Broussard could basically fund development themselves. Creative freedom is great, but without the business reminding you that what your building is for people to use and enjoy you run the risk of getting stuck into some sort of artwank vortex.

Fear of Success—gilding the lily

I’m not a console game developer, but when I heard it takes up to a year from “locking a game down” to launch I really felt sorry for those guys. The projects I work on have some level of locking down code to close out the last remaining bugs, but if it took a year, I can see how it would be an almost paralysing decision to make.

You’re no different from Nukem

To some extent or another, your project will have some of these issues. Or the server will blow up. If you don’t have complete freedom and never know when to finish the business will be on your ass. Or the IT department. Or someone else’s sucky APIs will kill you slowly as you realise you’re the first person to use them. Or you will get a fundamental set of assumptions so wrong that you need to reset. Or you hire someone that turns out to be worse than useless (and yeah – I know you will fire them quickly, but it will still suck energy and time from the team).

Once you realize that some or all of these things will happen to your project, you can start to use this information to your advantage…

Duke Nukem Forever is at the limit of how long things will take

See here’s the thing: Duke Nukem is pretty much at the outer limit of how long you can get away with a project overrunning. Any longer and it would have been be laid to rest. If it weren’t for the cult-like following DNF’s only achievement would have been 3 Vaporware of the year awards (and a lifetime award to boot). Gearbox Software, the company that picked up development after the original developer went bankrupt probably realized that they were better off launching a mediocre game and starting from scratch than suffering yet another rewrite. This gives them the opportunity to reset the ‘development time’ clock.

Enter the Nukem as a unit of development time

With all this in mind, I propose that we consider using the lesson of Duke Nukem Forever to give us a new unit of software estimation:

A Nukem: The amount of time a project or part thereof will take when pretty much anything that can go wrong does.

So – how long will your next project take?

I can’t be precise, but I can be accurate. This is how long your next project will take longer than you expect it to to and less than a Nukem. Or, in mathematical terms:

ψ < x < ω

Where:

ψ = the amount of time you expect it to take

x = the amount of time it will actually take

ω = a Nukem

What’s interesting here is that many of the issues that Nukem had weren’t really down to code or developers, yet developers are the ones who get asked to estimate project duration and get held to it. Oh well, tough shit, that’s what you get for being a creator. Broussard’s stock response of “screw you publisher, it’ll be ready when it’s ready” actually ended up killing his baby. Of course if you go to someone who is paying the bills with this range, you’ll probably not get vey far. But there is hope. In my next post I’ll show you how you can use this information to arrive at a range that is more palatable to them, has some science behind it, and allows the business to make some decisions based on your assumptions.