Quote:
At first I wrote flexible code. I figured that because I couldn’t predict the future, I better leave all the options open. The code was modularized, well-factored, with a lot of bells and whistles, and more than enough documentation. I was proud of it, until I learned that:
- Things changed so rapidly that even my solidest assumptions became false.
- The small flexibilities in the code were too small to be really helpful, yet too many to be easily refactored.
- In a world of 140 characters, nobody read my heavy documentation. Literate programming didn’t work, if ever.
- Longer code, no matter good or bad, is harder to maintain.
So, in another project, I switched to writing extremely tight code. I used a lot of functional abstractions and removed every single bit of redundancy. And documentation is, of course, left as an exercise for the reader. I figured that good code was deleted code, and short code could be easily refactored. I was proud of it, until I learned:
- 80% of the efforts had been spent on reducing 20% of the redundancy. Like speeding, it didn’t save much.
- Highly-factored, redundancy-free code can be difficult to document, understand and debug.
- The best way to compress some code is using gzip, not your hand.
Now I think, just like many things in life, a balanced position is the best. In other words: write simple code. I deeply believe that you can achieve simplicity without compromising on other aspects. I believe that applying the simplest solution which consumes minimal energy is how the whole universe works. When you get one simple answer, it may not be the right answer. However, once you find the right answer, it is usually also very simple.
I think we should just make it easy. If you feel difficulty when writing a program, if you find yourself scratching your head, either because of intricate structural design or abstract code factorization, you are probably doing it wrong. After all, you should be able to enjoy programming, not suffer through it. There is more than one way to do it – any approach can be a good start, as long as you feel easy and comfortable about it, and you do not forget to keep improving it. If it’s too fat, cut some; if it’s too thin, grow some. Eventually you’ll reach a point where you find ultimate simplicity. Call it fixed/optimal/equilibrium point as you like, it’s all the same thing. It’s just how the universe works.