Wired has a very interesting piece on how the Duke Nukem Forever project failed. It’s not only relevant because DNF is part of the nerd culture but also because it is a very interesting tale about a company that could not achieve a reasonable Definition of Done (DoD).

In software development we often talk about Done as if it was only a technical thing. It is not.

When developing a normal and bureaucratic system for a large bank or some similar client it is very unlikely that the DoD will be a problem at all –and if it becomes one it will most certainly be because of technical aspects as those mentioned in the list linked above. Things get a bit different when we are dealing with passionate people.

Projects with passionate people are always exciting. You can feel the energy, everyone is eager to help and improve the product. Everyone love what they do, really depend on the project to be a success or both. It is a fairly common situation for startups, creative agencies, the entertainment industry and media companies in general. And it is an awesome thing!

Having been to these kind of projects for most of my career, I know that the problems described in the Wired article are very common in there. Startups don’t want to present something that is not fully-featured and end up missing opportunities to enter a market, creative companies want to show their clients and users only the high-quality final version of the product, media companies are afraid to look like Muppets if their products are not one step ahead of everyone else since day one…

The Wired article seems to suggest that feature freeze is the key to overcome this problem, at least for the videogames industry:

It’s a dilemma all artists confront, of course. When do you stop creating and send your work out to face the public? Plenty of Hollywood directors have delayed for months, dithering in the editing room. But in videogames, the problem is particularly acute, because the longer you delay, the more genuinely antiquated your product begins to look — and the more likely it is that you’ll need to rip things down and start again. All game designers know this, so they pick a point to stop improving — to “lock the game down” — and then spend a frantic year polishing. But Broussard never seemed willing to do that.

I am no one to talk about how to manage a large code base written in esoteric C++ engines –I did that only once in my life and there is a reason I’m not going back there– and can’t really say if that is how that industry works/should be working; but I have to say that this is often not the best solution in the domains I mentioned before.

There are many strategies that I have used in this kind of environment. They often are either about showing that good enough is good enough or making sure people understand the costs of what they are doing.

A while ago I was employed by a big media conglomerate. Everything we did had to go through so many levels of approval and review that it could easily take months from a project kick-off meeting to when my development team received the graphic assets (PSD files, static HTML, etc.) and started writing code for it.

We had UAT servers where my team would deploy the application after each iteration, for the showcase and review. For those meeting we let the demo application point to the QA database. That database was populated with a dataset good enough to showcase the latest changes, but also had some garbage that was created by testers and developers in the process. One thing we realized at those reviews sessions was that the more database garbage displayed in a given demo the more rejected stories we would get in that meeting. After finding this out we decided to do something different.

For the upcoming releases, instead of using a UAT server to host the showcase we deployed the application straight to production. The old version would still be available in the expected URI but if you typed a URI that only our stakeholders knew you would get to the new version and that was pointing to the production database –sure you can’t do this with any application but most public facing websites wouldn’t have a problem. We used this secret URI in the showcases and by doing that we managed to get things approved much quicker: there was no noise in what the users were seeing.

But even with short feedback cycles there is still the problem of people changing the product all the time. Don’t get me wrong, it should be OK for a software development team to change things as requested, embrace change and all that. The problem is that, in the end of the day, if you change things all the time you will not deliver anything.

As Wired points out, that is a problem for the team, and an even bigger problem for the business as a whole.

Then a staff rebellion broke out. For longtime employees, the incessant delays posed two big problems. One was professional cred: Duke Nukem Forever was the only modern 3-D game some of them had worked on; if it didn’t ship soon, they’d have spent nearly a decade with nothing to show for it. The other was money. 3D Realms paid its designers less than many competitors, most notably id Software down the road. Broussard motivated them by offering profit-sharing. “Their business model was to pay the developers very low, but with a potential payday at the end that was pretty substantial,” says former employee Schuytema. As Duke Nukem Forever failed to arrive, so did that big payday.

As a consultant it is easier. I just remember the client that there is a bill to be paid in the end of the month and she would probably spend her budget more effectively if she tries to get some money from the system as soon as she can and then think about making it better. As a permanent employee for those organizations, I tried many different ways to convince people of the same thing. Turns out that this is really hard. Often business people are not in the same hierarchy as your team and you act as a service provider to them, with the difference that there is no bill to be explicitly paid. They just don’t care.

One thing that works in this scenario is the poker chips technique developer by Jason Yip. I’ve used that both as a consultant -pairing with Jason himself- and as a permanent employee for organizations -we didn’t actually have poker chips but tokens representing development hours.

It is amazing how one’s mindset changes when they stop thinking that there is a magic bag of infinite money and have to rationalize their decisions. You should give this a try.