Let me tell you why the last 20% of work takes the same amount of time as the first 80%

You know when developers tell you that they did 80% of the application in x days and that they need the same amount of time for the last 20%?

I was trying to find an analogy for »laymen« and I’ve finally figured it out.

This is the same as driving from suburbs to a city center in a rush hour. You make 80% of the distance in x time driving on a highway and then you want to turn from the wide highway to the city center and the traffic becomes stale. Traffic lights, crosswalks, roundabouts, Sunday drivers, you name it.

It is usually the same while programming. You begin by wire-framing and making the foundations of the project. You start developing and after x days/weeks/months when you are coming near 80%, the key functionalities look like they are doing what they have to.

But then, when you say that you just have to polish the product, the fun begins. This is usually the time when many bugs become known (“did you know that when you take away the USB from the computer while trying to read a file from it in the program, the program crashes?”, “looks like the program doesn’t want to download a file that has an exclamation mark in the name”…).

And when stakeholders want those last 20% to be done in less time, this looks like getting stuck in traffic, jumping out of the car and running the last few block by foot and not caring what will happen with the car as long as you come to the finish line in time. It is possible, but it is not wise.

Update: there is an interesting debate over at Hacker News