Shaming Yourself Into Better Code

Good UX Means Good Business

In a world where technology is rapidly advancing and user expectations are rising, it’s no longer enough to have an average user experience; to delight your users and surpass your competition you must strive for the exceptional.

Get the Guide

Last week Harry Roberts of CSS Wizardry posted an article that caught my attention. It was simply titled “shame.css.”
http://csswizardry.com/2013/04/shame-css/
He talks about the issue all developers face at some point in the life-cycle of a project – having to hack together code to get a defect fixed quickly. It’s the struggle between wanting to keep code clean and up to standards, and wanting to just get the thing fixed and out of your hair. I’m pretty confident in saying we’ve all done it, even though we know it to be wrong. And therein lies the rub. We’ve done something wrong, and now it is stuck somewhere in our code until we get around to making it right. Those exact circumstances are what (he is proposing) a shame.css file can be used for.
Any time you need to add some code you are not particularly proud of (for example: font-size: 18px !important, or *margin-left: 20px), don’t stick it in with the rest of your clean code. Put it in a completely separate file. Here are three reasons Harry gives for why this is a great idea.
1. You make them stick out like a sore thumb.
Any other developers working on the project with you – or any developers that join the project in the future – will be able to see all the hacks you introduce. This not only acts as a deterrent, as no one wants to be thought of as “that guy”, but (if properly commented) it also gives other devs the opportunity to see what problems arose in the past and how they were addressed.
2. You keep your ‘main’ codebase clean.
Pretty self-explanatory, but keeping all the bad code out of your main codebase means you get to keep everything neat and organized. No sense in mucking up your good code if there is another option.
3. You make them easier to isolate and fix.
Probably the most useful benefit of separating these styles is the ability to quickly and easily find them in the future. Hopefully if you are introducing a hack or otherwise poor code into a project to fix a defect quickly, you will come back in the future when there is more time to properly address the problem. Doing so will be a cinch with them already removed from the rest of the code.
With any new coding standard, there need to be a few rules and guidelines in place.

1. If it’s a hack, it goes in shame.css.
2. Document all hacks fully:
   1. What part of the codebase does it relate to?
   2. Why was this needed?
   3. How does this fix it?
   4. How might you fix it properly, given more time?
3. Do not blame the developer; if they explained why they had to do it then their reasons are probably (hopefully) valid.
4. Try and clean shame.css up when you have some down time.
   1. Even better, get a tech-debt story in which you can dedicate actual sprint time to it.

Developmentally, the goal of using a shame.css file is to eventually curb coding habits so that future use of such a file would be unnecessary. The more you add to the file, the more you would want to stop adding to the file, thus writing better code with fewer bugs. Of course, this goal is likely unattainable, but attaining the mindset of wanting to write better code is the true benefit.