The remaining 4 percent

There is something about giving an ETA that I hate. As programmer I want to say I never ever gave an ETA that was remotely accurate. In my experience an ETA is the nice way for a manager to give you a dead line. Countless times I have pulled numbers out of thin air only for the manager to suggest a different number (Well if you had a date in mind why do you waste my time). To me ETA is acronym to Estimated Time of Arrival. If we are talking, I have already arrived, don't ask me about it.

You are presented with a project you never heard of before, it was concatenated by a team of managers in a secret meeting you were not part of. It is a great idea indeed, but you as the developer, engineer, programmer, or the person who has to turn this code into a product are only hearing about it for the first time. They ask you to give your expert opinion on how long it will take to build. I don't know about you, but I usually don't have an answer.

Ok, you are a carpenter and you build chairs. You have built countless chairs in your career, you specialize in it. If I want a chair, I explain how I want it to look like and feel like vaguely (specs), you have a good idea how long it may take to build it because that's what you do; you build chairs. If however, I ask you to build a mahogany office desk, you would probably ask me to give you more than a vague requirement and ask for some time to figure out what is needed to build it. This seems completely fair right? Yes, they both require wood to be built but a kitchen chair and an office desk are 2 different things that require different processes to build.

For programmers, on the outside it all looks the same. What people see, and what Hollywood fantasizes about is that all you need is to code and voilà. Now let me tell you an undisputed truth: The biggest bottleneck for programmers is not a lack of ideas, it is the difficulty of the tasks at hand.

I am not saying it is impossible to make a good estimate on how long it takes to complete a project, but there are a few things that need to be taken into considerations. Each project have 3 parts.

The 95%

The 95 percent of a project is the easy part. You have a good idea of what you are building, all you have to do is create a structure and add the basic functionality. I call it 95% because on the web a project that is 95% ready is good enough to be exposed to the public. You can say "it will take me 3 to 4 days to build a CMS". Maybe more for a bigger project. At this stage, it sometimes feels like the faster you type, the faster you will get it done. You already know what you are doing. This part is followed by the next 4%.

The 4%

The 4 percent are the "unpredictables" you did not account for when designing the project. It takes time to fix. This is why there is no such thing as a product delivered on time without everyone working nights and weekends as the deadline approaches. If the project was scheduled to finish in 2 weeks, you will have to either work 24/7 till then or find a good negotiator to extend the deadline.

Elon Musk promised to have the falcon 1 in orbit in a year and a half. It took a total of six years for it to happen.

Putting pressure on the programmers won't help, it won't make them type faster; remember that how fast you type does not make you a better programmer, it just makes you type faster. Pressure actually make things worse. New bugs will be introduced and there will be no documentation to explain what each part of your project does. More times than I care to admit, I chose to create illusions of bugs being fixed (hard coding) instead of taking the long route of fixing it.

Those 4 percents may take even longer to complete than the 95 percent. If I can predict only the 95% part of a project which account for probably 30 to 40% of the time needed to complete it, what's the point being put on the spot to give an estimate for something that will take plus/minus 100 hours of what I will say? Maybe it will make some people look good in a meeting. Maybe by sheer luck I will be right and will be viewed as an expert while it quietly fuel my impostor syndrome.

How about the remaining 1%?

So 99% of the project is ready. In this case I am being generous and say 99%. In reality the remaining 1% which can grow to more than 20%. These are the things that will never get done because the project was too ambitious in the first place.

Lots of time is wasted in meetings discussing things that have little to no importance. The 1 percent usually ends up being cut off from the project. But it doesn't mean no one ever worked on it. Programmers are given those tasks. They work on it, they put time and effort, they are stressed, pressured to produce quickly. They build something they can be proud of then the task is swept away like nothing ever happened.

I have worked on many AB tests platforms in my short career. The "bosses" where never satisfied with the products we used. After iterating through multiple product, we decided to build our own. I was given a list of things the application should not do. Having worked with multiple AB test tools I knew what I needed to do. I created a new project on SVN, worked tirelessly for 2 months to build something that was perfect for the job. Every time I ran the tool, I felt the good cholesterol in my blood. A few days before the release, a manager read about a new tool that was making rounds on the internetz. Obviously we discarded our custom tool for the new one. Who cares that there is a learning curve and that it doesn't solve the problems we had before. Who cares that the custom tool was 99% ready.

If I was asked to build an AB testing application today, I will have a good idea how long it will take, because I have done it before. If you ask me however, how long it will take to port Excel into a 2D canvas. Then listen. Listen to me carefully because, I'm about to lie to your face.

---