Coding For Flexibility
This is more likely a more intermediate to advanced concept. It is important, nonetheless. As our experience and common sense grows with each code we create every day, there will be an urge to code for flexibility. By flexibility, it means having an extra piece of code that can be used in the future. It can also means taking shortcuts and think that we will come back to it later and improve on it.
Personally, with the current programming language we are using, getting a really flexible code is next to impossible. Why ? Because to be really flexible, the code will have to be able to adjust by itself. It needs to be an A.I. (Artificial Intelligence).
The current structure and method of programming is rigid and flexibility is created by us, the programmers. I have yet to find a programming language that can adjust code, depending on the situation it encounters. Everything has to be coded by us.
Thus, we are also responsible for our codes, especially how far we are going to code for flexibility. Each flexibility options means extra lines of codes. Codes that may or may not be used in the future.
David wrote on his post “Winning is the worst thing that can happen in Vegas” over at 37 signals, exactly on this issue.
Future coding is a lot like playing the roulette. If you can guess where the requirements of tomorrow will land today, you’ve just scored the ultimate programmer’s prize: looking like a wizard. You saw the future and you were right! High five, brain!
That’s the almost irresistible draw of “flexibility”—often just a euphemism for building half or whole features before you know how they’re supposed to work or whether you need them. Just like in Vegas, the worst thing that can happen is to be right about this once in a while.
Because like the casinos, the house of program complexity will take all your little bets on the future and add them up until you just don’t know how this damn program got so deep into technical debt!
His metaphor on Vegas and gambling is spot on. Gambling in Vegas by itself is neutral. It is the gamblers that are responsible for their action. The humans, not the machines or gambling system, are responsible.
Thus, much like gamblers, we, programmers are sometimes gambling in the name of flexibility.
The solution ? Just say no.
To take the scare quotes off flexibility, you have to be willing to write no code at all. The “Simplest Thing That Could Possibly Work” and “You’re Just Not Going To Need It” are both sayings to help you get there.
This really does mean not a single parameter to a method that has not yet found a use. No needless public methods that might get reused later (not even for testing!)
The hardest—and yet most important—thing in the world of design is the conviction to say no.
Remember, sometimes, no code is good code.