Anti-patterns

It has been a few days since I had written my last post. I was a bit swamped by work for the past few days. The fact that I suddenly lost balance in my work and other things in my daily routine made me think hard about what good and bad habits I have about accomplishing things and solving problems.

For that, I referred to the recently encountered list of anti-patterns. Apparently, the term was coined by the guys who wrote the book called Design Patterns and was popularized by the book called AntiPatterns.

I am listing some of the interesting ones from the list that I thought were especially pertinent to me.

Analysis paralysis

It means that you are simply stuck in the analysis phase and unable to move forward. It often occurs to me and becomes a huge time sink. What I would need to do whenever I realize that I am having the paralysis is to quickly set in stone the things that are absolutely sure first and start from there. Then, start working toward making the uncertain certain once I have the basic things implemented or take care of.

Lost in the weeds

It means a delay in decision-making due to excessive focus on details. I often find myself trying to clear out everything before I begin. However, what I should be doing instead is that I should have the high-level confidence as to certain things would work if gone a certain direction or done a certain way. Once I am sure about the direction, I can start thinking about the implementation then.

Ninety-ninety rule

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.

— Tom Cargill, Bell Labs

So, I guess this means that I need to account for the other 100% of the time it would take for me to complete the remaining 10% of the project. What I usually do is for the first 90% of the work, allocate 70–80% of the time, and spend the rest 30–40% of the time for the rest 10% (which usually ends up being testing, refactoring, debugging etc). Therefore, I was missing about 20–30% extra time needed for me to sufficiently complete the project. It seems that the work for the last 10% is about 9 times slower than the first 90%. Next time I plan for a project, I will first think of how much time it would take me to go to 90% and then multiply that by two to get the total time I would need for the project.

Scope creep

This means the continuous growth in project scope after it has been finalized. This usually would result in never finishing the project. Although this has happened not as often as the other ones above, I sometimes feel the urge to go ahead for the scope creep. Always stick to the original plan. Think about the next step after completing the nearest milestones.

The rest were more or less programming specific ones, so I will skip them for now.