Paint the room heuristic
Submitted by sbarber on Fri, 30/06/2006 - 02:08.
metaphors
The other day, my wife asked me if I could finish painting the bedroom before my conference call in 90 minutes. Naturally, I said that I could and like a good husband, I immediately got started. It wasn't until my phone rang that I realized that I hadn't made it in time. Luckily enough, it was no problem to delay the call by 30 minutes.
While I was finishing up, I realized what had happened. When my wife asked me if I could accomplish the painting in a certain amount of time, my thought process was...
1)If I do it now, it will make her happy.
2)If it takes a little too long, the worst that will happen is that she'll be a little grumpy until I finish, but once I'm done she'll be happy.
3)Once I start, no one is actually going to make me stop before I'm finished... I mean, who wants a mostly painted room?!?
4)I completely overlooked the fact that delaying the phone call could be problematic.
It occurred to me that we often estimate our software development or testing tasks this way...
1)If we say we can do it by the deadline the boss is asking for, the boss will be happy.
2)If we don't get done in time, that's ok, because we'll never ship on time anyway, so the boss won't mind.
3)Once we start, we can always get an extension... I mean, who wants a mostly tested/developed application anyway?!?
4)We completely overlook that missing those deadlines sometimes have severe consequences.
The fact is, as a whole, we are often no better at estimating how long development/testing will take then we are at estimating how long painting a room will take, but we often approach it with the same attitude... i.e. Well, as long as we keep making progress, we're going to be allowed to finish and once we finish, people will be happy and forget that it took longer than expected.
Experience says this simply isn't true. Projects get canceled for running over time. Companies lose money. The market window is missed. People get laid off. Missing these deadlines is a big deal! We know that! But if we know that, why do we estimate our time the same way we estimate painting a room? I don't know the answer, but I certainly think it's an interesting question.
While I was finishing up, I realized what had happened. When my wife asked me if I could accomplish the painting in a certain amount of time, my thought process was...
1)If I do it now, it will make her happy.
2)If it takes a little too long, the worst that will happen is that she'll be a little grumpy until I finish, but once I'm done she'll be happy.
3)Once I start, no one is actually going to make me stop before I'm finished... I mean, who wants a mostly painted room?!?
4)I completely overlooked the fact that delaying the phone call could be problematic.
It occurred to me that we often estimate our software development or testing tasks this way...
1)If we say we can do it by the deadline the boss is asking for, the boss will be happy.
2)If we don't get done in time, that's ok, because we'll never ship on time anyway, so the boss won't mind.
3)Once we start, we can always get an extension... I mean, who wants a mostly tested/developed application anyway?!?
4)We completely overlook that missing those deadlines sometimes have severe consequences.
The fact is, as a whole, we are often no better at estimating how long development/testing will take then we are at estimating how long painting a room will take, but we often approach it with the same attitude... i.e. Well, as long as we keep making progress, we're going to be allowed to finish and once we finish, people will be happy and forget that it took longer than expected.
Experience says this simply isn't true. Projects get canceled for running over time. Companies lose money. The market window is missed. People get laid off. Missing these deadlines is a big deal! We know that! But if we know that, why do we estimate our time the same way we estimate painting a room? I don't know the answer, but I certainly think it's an interesting question.