Programming is all about decision making

As a programmer, you are continually making decisions when you program. Both at the macro level and the micro level. For any project, you have to select the programming language, the tools and the environment. Then as you design, you have to choose continually among multiple ways of doing anything. As you code, you continually are choosing among many ways to write the code. You are continually reformatting and rearranging code and even refactoring because you are not able to decide if one way
is  better than another. The problem is that, usually, the decision making required is trivial. But the sheer number of times you have to decide stuff is what slows down any programming task.
I think people who complete / finish projects are people who do not sweat over all details when programming. For most decisions, when the need to make a decision arises, they quickly choose one of the two or more choices without thinking about it and do not second guess their choice. So they continuously make progress and take one path to the end — they do not spend their time vacillating over what to do at each decision point. If some decision was really bad, it will become apparent enough — then you only need to decide (:-)) if you need to rewrite the part of the code starting from where a wrong decision was made.


What does the bis in the 2547bis RFC stand for?

Google search revealed that “bis” means “twice” in Latin and the bis in 2547bis refers to the fact that this is the 2nd edition of the original 2547 RFC with updated sections. Who would’ve thunk?


“Premature Flexibilization”

The author of  this coins a new phrase — Premature Flexibilization:

…the practice of adding complexity to your code to make it more “flexible”, in anticipation of future change.

The article, triggered an “yes” response in me 🙂 because I felt the same way many times.

In all my coding, I find that I waste a lot of time doing exactly what the author of that article calls “premature flexibilization” — trying to make code as generic as possible, trying to cover many cases that are currently not present, trying to cover all kinds of input. Though it is a good habit, I find that it contributes negatively to project completion and most times, all the genericity, etc was really not used. I have found that it is better to follow the agile practice of YAGNI and code to the current exact requirement and later go back to refactor code when another requirement for the same code comes it to make the code flexible and generic to cover the original and new cases. That way the code goes organically, does exactly what is required and the project gets completed.

One thing though is that it requires some discipline when revisiting the code the second time around to make sure that you test the original requirement is still being met.

I think one of the reasons for the effort spent in making the original code flexible is so that I don’t have to revisit code (mentally for me code maintenance is possibly one of the hardest thing to do).