*
programming and human factors
by Jeff Atwood
*
You may think you've completed a software project, but you aren't truly finished until you've conducted a project 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?
I heard that Elvis was recently spotted playing Duke Nukem Forever!!!
=P
The Geek on December 1, 2006 9:13 PMSome people prefer the slightly less morbid version, the "retrospective".
Kevin Dente on December 1, 2006 9:42 PMWhat I've seen happen historically is that people get in a room, whine, whine, whine and then consider their job done and forget about it.
DMB on December 1, 2006 10:30 PMThe challenge is knowing when a project is complete. Unlike a game, which has a clear definition "When we ship", some projects seem to drag on indefinitely with change orders, etc...
Sometimes we hardly noticed that a project has transitioned into the maintenance phase.
So consider "MidMortems" along with Post-Mortems. These would be "retrospectives" at significant milestones within a long project.
Haacked on December 1, 2006 11:33 PMYour blogposts are too interesting. I was just going to sit down and check the mail, and now I've been here for an hour, reading, following links and (almost) ordering books.
Shame on you. :)
Mats Gefvert on December 2, 2006 3:15 AM"Some people prefer the slightly less morbid version, the 'retrospective'."
We prefer the much more descriptive term "Afterbirth", because it's such a bloody mess. :D
Randolpho on December 2, 2006 6:03 AMOr simply use the term process evaluation. I used to do this during projects at uni, in the real world (as Jeff points out) I have yet to see one performed. Indeed, there's hardly time to polish off and ensure the quality of the project already. A shame really.
Casper Bang on December 2, 2006 10:49 AM> Some people prefer the slightly less morbid version, the "retrospective".
Yes. Boring people.
C'mon, where's the excitement in "retrospective"? Don't you want to bust out a little CSI action instead?
Jeff Atwood on December 2, 2006 3:02 PMVery interesting. I'm sat here on a bright December morning preparing for a post-motem I've organized for tomorrow morning and decided to check my bloglines account when I came across your article.
Good stuff (esp. the links)
Cheers
I said some people, I didn't say me. :)
The way many projects go, perhaps autopsy would be a more appropriate name.
Interesting. Perhaps I'm one of the boring people but I don't much like the word "post mortem." I guess that's 'cause the projects I've worked on have been successful.
We tend to hold retrospectives, but don't do them at the end .. we hold them after every release (once a month), and they're short. It's amazing how much more productive and cohesive (they don't always go hand-in-hand -- sacrificing a little bit of short-term productivity for long-term inter-relational work is a hard sell, but valuable) a team is when it's continuously reflecting on its successes and failures.
Here's a book that will help:
http://www.pragmaticprogrammer.com/titles/dlret/
I generally respect most things out of the Pragmatic Programmers, and this one's no exception. If you reflect on your project more often, and the team has more of a stake in the way they operate, then the project has a better chance of success, in my opinion.
Oh, and I swear, I am not, nor have I ever been, a consultant. :-) In-the-trenches developer/retrospective facilitator here.
Stephen on December 3, 2006 7:56 AMMy employer has recently ended post-mortems. The exec in charge thinks they don't produce useful results. I'm sort of at a loss to respond to this depth of cluelessness.
kokorozashi on December 3, 2006 1:22 PM"Our goals were too amitious and our timeline too optimistic."
I've never heard anyone say, "it was a bad design or that that any technical decisions were a mistake."
The only useful feedback seems to have been, "we didn't reduce dependancies enough."
Eric on December 4, 2006 5:23 AMI'm a big fan of the postmortem in making me a better developer, but I'm usually a little nervous to have them since I'm usually the lead programmer, and managed most of the project outside the money issues. I'm the only one to get the blame for failures.
It seems like at the end of every project, the final conclusion is always "we should have had a better statement of work"
Seems like I would have that one figured out by now.
Haacked is completely right though. Most of the projects that I'm working on now don't have a ship date. They just transition into a new phase of the project - be it maintenance or adding features.
I do have those SOWs down though. You bill by the hour, keep track of every little thing you did. If you spent 15 minutes writing an email to explain how to use the system, you can bill for that later. At the end, just send them your spreadsheet of every hour you worked and bill. I love working like that because timelines and scope-creep are no longer issues. Blissful.
Ryan on December 5, 2006 12:33 PM| Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email