Because of previous experiences, I always take great care to try to write clean code that is easy to maintain.
These efforts have paid off! I have always received positive feedback — and at worst (best?) a helpful pointer — from colleagues who have reviewed my code.
Is Conscientiousness Obsolete?
As things change more and more quickly, some people might assert that being careful is no longer important, because today’s technology will soon be obsolete. More and more we see this, as technical debt increases to the point where legacy systems require total replacement.
This is certainly a valid point, and we need to be mindful about how much time we spend chasing an idea down a rabbit hole and trying to make things just exactly perfect.
Not So Fast!
Another side to this idea is that, because things change more quickly, it is our professional responsibility to help others embrace this change by writing more maintainable code.
As the trend away from full-time employment towards temporary gigs continues, it becomes more important for the next person — whose experience may be vastly different from our own — to be able to quickly understand how the current system works, so they can quickly make the desired changes.
My Personal Preference
Obviously, I can see merit in both sides of the debate.
But to be perfectly honest, I prefer to be conscientious, perhaps because it’s in my nature (I grew up with a lot of guilt).
When done with a project, I like to feel good about what I’ve done. I like to be confident I’ve done a good job and didn’t just “hack something up” to meet a deadline — not that there’s anything wrong with that — provided it’s what the customer wants.
Here are some techniques that can help alleviate possible misunderstandings when it comes to quality:
- If you are planning to replace a system and just need a very few minor but important changes made, be sure to state this up front, so that we know that in this instance quality is unimportant.
- Setting a fee for the finished product, based on its value to the customer, is preferable to paying for work by the hour. The set fee scheme alleviates the risk of unwillingly paying more for “high quality,” which can be difficult to define and in some cases even be totally undesired.
- Stating up front that your company is on a strict budget and at this time cannot afford any extra expense for “high quality.” If you are interested in improving things once the company’s finances stabilize, this is good to know, because we can leave “TODOs” in the code to help the next person.
- Building a “quick and dirty” prototype. A true prototype should be built with the intent of discarding it and starting over from scratch, if and when it proves the viability of your ideas. If you think the prototype might go into production at some future date, be sure to mention this up front.
In my experience, few clients will say they do not care about high quality, but their preference makes itself apparent in other ways, which can be unfortunate.
Direct communication is always preferable to nuance — which is easily lost when working remotely.
Over-Thinking or Due Diligence?
I like to take my time when solving a problem. More than once I’ve coded up a complicated solution, only to take a look at it and figure out a much simpler way to do the same thing.
I like to come up with multiple solutions and pick the best one, rather than rush to implement the first idea, even though the initial solution might be sub-optimal.
Communication is Key
Moreover, if I am working for you on an hourly basis and you prefer I deliver an end result that might be something less than “just exactly perfect,” please state this up front.
Properly communicating your preferences allows me to keep an eye on the finished product and deliver an optimal result, regardless of whether we agree on what exactly constitutes “high quality.”