According to general wisdom one should measure twice and cut once. This makes sense in most professions and even generally in life; when you should think twice and open your mouth once. However, again, generally in programming, we have this ++ approach. There was C then C++ came out. Looking at the list of programming languages on Wiki, I can see 8 records with ++ in their names. Not every ++ is related to the programming language it’s named after. For example R++ has nothing to do with R which is a statistical programming language whereas R++ itself is C++ related.

That being said, I’m going to take a naive approach and apply ++ logic to measure twice and cut once and make it measure twice and cut twice.  First and foremost, this is going to be an empirical approach and my basis for this theory is the experience I have gained in 15 years of building static and dynamic websites, web and desktop applications. However, I hope that it’ll make sense to most of you, especially to those who obsess about details and perfectionism.

Pareto principle

This principle is known as 80/20 rule. There are many ways to interpret this principle. Some think that 80% percent of the effort or gain is achieved by spending 20% of the total time that’s put in as opposed to 20% of the project will take 80% of the project time. So, it’s like you spend more time, resource or whatever is relevant to your case to make even less gains. It’s that home stretch feeling that comes with anxiety and unsureness about ever getting to the end. Think Frodo and his bloody ring. At the beginning everything may seem Shire and near the end a bit more dire…

Now, all this stuff may look like it’s got nothing to do with programming but here is what occurred to me. Why does it feel that I spend more time for fussing over details and simplicity of my code versus spending so little time to actually write bulk of the algorithm? The heart of the program usually takes such a short amount of time that at that point most programmers worth their salt actually feel whether the proof of concept has been achieved or not. So, why then we spend more time fixing our code and satisfy that itch in our souls that such elegance has been attained? Does it feel  more like a worthier effort since we have endured such a longer journey?

Can We Do Better Than 99%?

The symptom I presented above is actually known as ninety-ninety rule in programming and quoted by Tom Cargill as:

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

I purposely  wrote the question in the title wrong because 90-90 almost resembles 99. Certainly, 90+90 is worse but let’s just say we’re trying to achieve 99% happiness with our code, whether it’s that one liner or separation of concern or modularity. The reason why I picked 99 is because it’s a good number close to 100 and it might actually signify the success rate or the level of completeness we would like to achieve. Let’s try to see this 90-90 or most simply 99 from 80/20 point of view.

Imagine we are doing 80% of the work. That’s measuring once. For the remaining 20% of the total work you will actually spend more time compared to the first cycle and to what gain? You’ll only get 80% of that 20% of work left from the first iteration. Hence, achieving a total success rate of 96% in total! For each consecutive iteration to raise this number there is going to be an ever growing effort, bigger than previous attempts. This is also known as diminishing gains.

Measuring twice and cutting your effort right there actually gets 96% of the job done. So cut once after each measure and measure twice, you are done! I’m of course not saying this should be the level of completion for a project’s deliverables. This is merely an attempt to accept that there has been a good enough effort and as long as acceptance tests pass and you get green light from the client, it means good enough!

It should be good enough for you as a freelance or practicing programmer as well. I bet no client would care about that 4% of gain that would take so much time for refinement and elegance. Neither should you care. Think about it. From a programmer’s point of view, if this piece of code is for a hobby project, it would mean the cost of opportunity. You could be learning another programming language or honing your existing skills on a new challenge.

I’m actually going to write down how much time I spend for certain tasks and compare the level of happiness with my code to how much time it takes between each layers. I’d like to back my claim with numbers if possible but it seems to me that measuring twice will most likely be enough.