Photo by Eric Wesseling

Doing “premortems” for software projects

I’m currently reading the fantastic book “Thinking Fast and Slow” by the Nobel Laureate Daniel Kahneman. In the section on optimism and over-confidence he introduces the idea of the “premortem”. It’s as it sounds: the inverse of a postmortem analysis. In his words here is the prompt:

“Imagine that we are a year into the future. We implemented the plan as it now exists. The outcome was a disaster. Please take 5 to 10 minutes to write a brief history of that disaster.”

The exercise is meant to make you ponder the issues that could crop up and avoid “group think” and over confidence that comes with it once a course has been set. The thing is, I think you can apply it to your own side projects and plans and it can be just as effective.

Software is complicated, estimating is hard, blah blah blah

Everyone knows software is hard to estimate. It is difficult to predict which third-party API will cause your trouble and what last minute requirements the business will pile on. I’m a developer and I do side projects and freelance work, so I’m thinking on a very small scale here. I don’t practice agile like I do at my day job, and I don’t have planning meetings with myself, but injecting more thoughtfulness into the process can help.

What a premortem can help you do in a solo effort is to sit down and characterize the things that may not go your way and give you an opportunity to plan to respond to them before they become major hindrances. And If you can avoid something up front that will later become a maintenance nightmare that is worth plenty. So, I think sitting down and doing the exercise is worth the 5-10 minutes in the long run. In fact, you probably already do this and I’m just putting a name to it here and formalizing it.

Actually I should mention here that there are plenty of formalized planning systems including SMART criteria and SWOT analysis, but the premortem is nice because it just one additional little thing you can do, regardless of your other processes.

Looking back, is there any project I would not have done?

Well, lots actually. I have done (well, started) of a lot of side projects that could have benefited from a premortem. In the past I have started projects where I wrote a lot of code, had fully built prototypes, and then did not know what to do next. I feel like premortems could have helped me a lot there.

One project in particular, where I was building job tracking software for small contractors makes me cringe when I think back to it (I called it JobMinder). I could have foreseen the problems had I sat down and put in some thought. I didn’t have a clear idea of who my customer was and what I was building. I kept adding features before I even had a single beta tester. Then I slowly pursued beta tester companies with luke-warm enthusiasm for a while before losing interest myself.

Who was my customer? Am I intensely interested in this idea? What is my user acquisition strategy? What features will be in my MVP? How much time will this take? How will I work on this while I have a full time job? I hadn’t answered any of these questions.

If I had done a serious premortem I would have checked myself rather than charging ahead with undeserved and unrealistic self-confidence. I don’t think any planning methodology would have helped me. I was just so stupidly sure of myself and was not ready to think out in detail the mechanics of getting from code to customers.

What about a “Bias for Action”?

The one thing I don’t like about the idea of a premortem is that they are so inherently pessimistic that they could cause you to give up on a idea that could be rather good. I think when most of us are on our deathbeds we will be regretting more things we didn’t do as opposed to those we did. Anyway, that is at least the conclusion I have come to after reading many biographies recently. So I don’t necessarily think it is ever good to discourage a bias for action.

What I do think is that the premortem should not discourage you from doing a project, but it should make you focus on the rough edges and crystalize your plan a bit more before you start. If not that much, at least it should cool your unbridled enthusiasm and the resulting over-confidence that always comes with the rush of starting a new awesome project. In summary: still take risks, but mitigate them by imagining disaster.

Lastly, what about prototyping?

I think there is a difference between fully committing to a new project and working on a prototype. I don’t think you should apply a premortem to a project that is merely exploratory in nature. Building prototypes with minimal constraints can be fulfilling, and for a programmer it can be a great way to open the creative floodgates get into a “flow” state. Nothing should stand in the way of that.