100%

The pursuit to reach 100 percent is one of the most demanding tasks. It's not endogenous only to software development, but as I see, it's more prevalent here.

This is when you get obsessed to reach the magical 100% at all costs. But the price tends to get disproportionately high when you approach the latest percentage points, up until it just doesn't worth it anymore. But the closer you get, it's harder to stop.

One of my examples to this pursuit is to try to cut some bytes off a webapp. The first three things you do is: concatenate, minify, gzip. These are the easiest, safest, and yields the greatest results.

But then, there are a few other techniques to pare off some more bytes. Variable mangling (the shortening of variable names), and using a different minifier with more advanced optimizations are two examples. As every single byte transferred has a cost, shaving them off to the greatest extent possible seems like a worthwhile goal.

The first three approaches are easy, nearly all build tools support them, they do not break your code, and they shrink the package by like 80% of the original size. It's a tremendous amount and requires only a little work.

On the other hand, mangling might yield an additional few percents, but it can potentially break your app. This was the case with AngularJS 1, that used variable names to inject dependencies. The minifier broke the code when it changed the names.

Using a different minifier might again add a few percentage points to the overall compression, but might be less supported or requires some custom coding on your side.

Compare the 80% for like 15 minutes of work to the next single-digit gain that might take hours and add to the long-term maintenance. Does it worth it? Usually not.

Another example is test coverage. What do you want to test? Everything!

Wrong answer. You'll end up with a lot of tests that never break, and you need to spend a lot of time developing and especially maintaining those tests. Also, writing some of those can be a real challenge. For example, auto-testing visual components are usually hard, and there might be some other technologically challenging parts too.

You might have already heard about the Pareto principle. It says that 80% of the benefits come from 20% of the work. People tend to get obsessed with these figures, but the exact numbers are not important. Remember that most of the results come from only a fraction of the work.

When there are many parts, and the results are necessarily correlate with the efforts needed, there will be some low-hanging fruits that yield greater benefits for a low cost, and difficult parts with little gains.

By choosing the tasks with the highest ROI, you can maximize the results-to-work ratio. As a rule of thumb, do only the tasks that you deem worthy, and don't get obsessed with doing everything.

As always, there are some exceptions to this, where guarantees are needed for a given property. For example, all existing tests must pass all the time. And the build must yield zero warnings.

Takeaway

The amount of work needed to reach 90% is usually comparable to that needed for the remaining 10%. Don't be obsessed with perfectionism. Take the low-hanging fruits and move on. With the same amount of work, you'll achieve a lot more.