Back here in India, we are prone to finding bad roads, with potholes. Usually, once the road has been newly laid, its all neat and really great to drive on. A few rains, a few months later, there are pot holes everywhere! The only plausible explanation is the quality of tar and other material used to lay the road. And the people to blame are the Contractors. Most Contractors in a bid to make money use poor quality material to get the road laid.
Once the bad road has been laid, and after a good load of people have suffered using them, they start off with patch work, this is usually taken up by a different contractor (The old contractor cant be trusted anymore). Now, patch work is never good, there are odd lumps on the road, and the drive, though not as bad as the previous one with the potholes, is still not great.
We wait a little while longer, there are more potholes, and this time even the patch work has started to wear off. Now people have to lay a fresh road. And once again the vicious cycle continues.
When I was riding by today on a bad road, it chanced by my mind. Isn’t that exactly what we see here, in the software industry. We usually get projects wherein we find that the code has been really badly written, and we are given the task of fixing it. Or in some cases, bad code which we have written, ends up in another person’s kitty to clean up.
Why do we write bad code? Aren’t we also like these bad road contractors? Getting some one to clean up our mess, or get it in a state bad enough that it has to be re written from scratch?
People think its a headache to use the write design pattern, that breaking down our objects in to smaller, more usable objects is just some big daunting task. Or for that matter, using the right variable name, or closing that curly brace properly is just too much to do. I keep telling people that code should look beautiful.
Code, to us programmers is like how a painting is to an artist. Unless it looks beautiful and magnificent, it’s just not complete. We’re not experts or gurus to just weave out great code, but even a small effort such as using the right variable names, using the right code wrapping style, breaking down your objects into more smaller, manageable objects is surely going to go a great deal in making your code better, more maintainable and more extensible.
Writing code that works is not the right approach. But writing good code, that works, efficiently and allows for extension in the future is the right approach.
I was introduced to Design Patterns by two friends, Senthil and Kumaran. Ever since, I find myself trying to write better code. I know I still have a long way to go. I want to be a great Road Contractor. And I know that spending that extra time to get my code look beautiful, is going to get me there.
Other Resources that I’ve found of really great use
- Object Calisthenics, an idea suggested by Jeff Bay in The ThoughtWorks Anthology
- Design Patterns, by the Gang of Four
- The Passionate Programmer, by Chad Fowler