Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
Brian Kernighan from The Elements of Programming Style, 2nd edition, chapter 2
“Simple doesn’t mean stupid. Thinking that it does, does.” - Paul Krugman
Have you ever worked with a piece of that that made you think: "The person who created software was really smart - like a lot smarter than me"?
I have and when I was younger I was impressed, but as I have seen a lot of 'smart code' I am not impressed with it any longer.
Have a look at this Perl one-liner for instance:
find . -name '*~' -print0 | perl -0ne unlink
Honestly, I don't know what it does and figuring it out is almost hopeless. BTW Explain shell at your rescue
In the Perl community, there was a culture of making one-liner that would do magic. And that is exactly the problem with that culture - magic.
Code that is not simple and clear to understand is a pain to maintain and will slow you down. When the code is overly complicated and not simple, it could just as well be magic.
Remember: when we amend the code, we have to understand it first, and then we can change it. Of course, a good test suite will help you with the understanding and the confidence while changing it.
Some times I have seen people who did not try to understand the code before implementing a bug fix or a change.
This can of course be due to two things:
- The code is too complex to understand
- The developer is too lazy to spend time understanding before moving on.
The solution to 1 is actually to understand the code and then make time to make it understandable.
As a software developer, it is a pleasure to create a piece of code that is pretty complex - it makes you feel smart in - the moment.
But it is better to work a bit longer on this problem and make it readable and understandable for the next person, who takes over the code after you.