Aaaaand my code is ugly
Close up wet persian cat eye image via Shutterstock
It’s better to write ugly code than to produce bad, incomprehensible code that can only be cleansed with fire. In the end, what matters is the product. Right? Right?
If you were to choose between writing bad code and ugly code, which one would you choose? Which one is the safer road to good, clean, maintainable code?
Dirty code is not a pretty sight for Dr. Rebecca Parsons, CTO at ThoughtWorks, but, in the end, it is the lesser evil. Dr. Parsons admitted in front of her audience at the Continuous Lifecycle conference that even though the academic in her advises developers to stay away from ugly code, software quality is the differentiator because ugly code can be fixed but bad code is harder to change.
Should developers care about code beauty?
A lot of developers create ugly code and simply ignore it because they choose to focus their energy elsewhere. That might not be advisable but this strategy helps them get things done. François Zaninotto, CEO at marmelab, wrote in a blog post three years ago that it’s not developers’ job to care about code beauty — instead, they should focus on the product they are creating.
Zaninotto urged developers to think about the business value and put themselves in users’ shoes: what matters more: solution A which works but has ugly code or solution B which also works but has beautiful code? The answer is the following: users care about a good product which withstands the test of time.
Although he claims that what matters is the result and not what’s under the hood, Zaninotto does mention that developers should not write ugly code on purpose.
When is it ok to write ugly code?
You set out to write beautiful code but you end up writing messy, ugly code. What now? As Dr. Parsons said, code should not be ugly and if it gets messy, you should get rid of everything that looks bad. However, if the code is working and you can safely move on to the next phase, its good looks don’t matter that much. Brandon Savage, author of Mastering Object Oriented PHP, opined that sometimes it is more important to solve the problem and worry about the rest later.
Some of the people who commented on his blog post agreed that developers write bad code when they have tight deadlines to respect, especially if the boss says that it can be cleaned up later (whatever that means). If it’s a prototype, even better! According to one of the commenters, there are some tricks one can use to ensure that the quality can be easily enhanced at a later time, such as using encapsulation and Design Patters and creating a separated project (to safely try small pieces of features).
If writing clean, maintainable code is not a top priority for you, think about this old quote (which belongs to either Martin Golding or John F. Woods —depending on whom you ask) which goes like this: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
What are your experiences with ugly code?