The Project Postmortem

Jeff Atwood

30 Nov 2006 — 2 min read — Comments

You may think you've completed a software project, but you aren't truly finished until you've conducted a project postmortem.

doctors, postmortem

Mike Gunderloy calls the postmortem an essential tool for the savvy developer:

The difference between average programmers and excellent developers is not a matter of knowing the latest language or buzzword-laden technique. Rather, it can boil down to something as simple as not making the same mistakes over and over again. Fortunately, there's a powerful tool that any developer can use to help learn from the past: the project postmortem.

There's no shortage of checklists out there offering guidance on conducting your project postmortem. My advice is a bit more sanguine: I don't think it matters how you conduct the postmortem, as long as you do it. Most shops are far too busy rushing ahead to the next project to spend any time thinking about how they could improve and refine their software development process. And then they wonder why their new project suffers from all the same problems as their previous project.

Steve Pavlina offers a game developer's perspective on postmortems:

The goal of a postmortem is to draw meaningful conclusions to help you learn from your past successes and failures. Despite its grim-sounding name, a postmortem can be an extremely productive method of improving your development practices.

Game development is some of the most difficult software development on the planet. It's a veritable pressure cooker, which also makes it a gold mine of project postmortem knowledge. I've mentioned my fascination wth the Gamasutra postmortems before, but I didn't realize that all the Gamasutra postmortems had been consolidated into a book: Postmortems from Game Developer: Insights from the Developers of Unreal Tournament, Black and White, Age of Empires, and Other Top-Selling Games (Paperback) . Ordered. Also, if you're too lazy for all that pesky reading, Noel Llopis condensed all the commonalities from the Game Developer magazine postmortems.

Geoff Keighley's Behind the Games series, while not quite postmortems, are in the same vein. The early entries in the series are amazing pieces of investigative reporting on some of the most notorious software development projects in the game industry. Here are a few of my favorites:

Most of the marquee games highlighted here suffered massive schedule slips and development delays. It's testament to the difficulty of writing A-list games. I can't wait to read The Final Hours of Duke Nukem Forever, which has been in development for almost ten years now. Its vaporware status is legendary-- here's a list of notable world events that have occurred since DNF began development. "When it's done", indeed.

Don't make the mistake of omitting the project postmortem from your project. If you don't conduct project postmortems, then how can you possibly know what you're doing right-- and more importantly, how to avoid making the same exact mistakes on your next project?

What does Stack Overflow want to be when it grows up?

I sometimes get asked by regular people in the actual real world what it is that I do for a living, and here’s my 15 second answer: We built a sort of Wikipedia website for computer programmers to post questions and answers. It’s called Stack Overflow. As of

Civilized Discourse Construction Kit

Occasionally, startups will ask me for advice. That's a shame, because I am a terrible person to ask for advice. The conversation usually goes something like this: We'd love to get your expert advice on our thing. I probably don't use your thing. Even

How to Stop Sucking and Be Awesome Instead

I've been fortunate to have some measure of success in my life, primarily through this very blog over the last eight years, and in creating Stack Overflow and Stack Exchange over the last four years. With the birth of our twin girls, I've had a few

Books: Bits vs. Atoms

I adore words, but let's face it: books suck. More specifically, so many beautiful ideas have been helplessly trapped in physical made-of-atoms books for the last few centuries. How do books suck? Let me count the ways: * They are heavy. * They take up too much space. * They have