Handling Hacky CSS

Handling Hacky CSS

Even if you’re a CSS wizard, sometimes you need to take shortcuts. Quick fixes like using !important to make a third-party library override, changing browser-specific behavior, or a temporary fix for a production issue. These aren’t perfect solutions, but in the real world sometimes you just have to use them.

You have two options.

Mix these quick fixes with your main styles, hoping the code reviewer will be too lazy to spot them. This might work for a while, but these temporary quick fixes often end up staying there much longer than you intended, turning into a permanent part of your code.

// TODO temporary fix

The second option is a bit more open and organized. It involves collecting all these hacky solutions in a specific file. This file becomes a sort of to-do list, reminding you and your team that these are temporary solutions that need proper fixing later on. It’s about being honest with your code, recognizing that while you sometimes have to cut corners to meet deadlines or fix urgent issues, you’re also committed to coming back and doing things right.

This file by convention is called shame.css and should make you feel a bit guilty.

The Rules of shame.css

To effectively use this process, it’s important to establish some ground rules, in order to avoid shame.css becoming a dumping ground for all sorts of code.

1. Criteria for Inclusion: The primary rule is straightforward. If it’s a hack, it goes into shame.css. This includes any CSS that you use as a quick fix, which does not comply with the best coding practices but is necessary under the circumstances.
2. Comprehensive Documentation: Each hack must be accompanied by detailed documentation. This includes explaining the part of the codebase it relates to, the reasons for its necessity, how it provides a solution, and potential strategies for a more sustainable fix in the future.
3. Avoiding the Blame Game: The purpose is not to blame developers for using hacks but to acknowledge the realities of software development. If a developer has resorted to a hack and documented their reasons, those reasons are likely valid under the circumstances. The focus should be on understanding and eventually resolving these issues, not assigning blame.
4. Regular Maintenance and Refactoring: It’s essential to periodically review and clean up the code. This can be done during downtime or as part of regular code maintenance. An even better approach is to include refactoring tasks in your development sprints as a tech-debt story, dedicating actual sprint time to addressing and resolving these hacks.

Conclusion

To wrap it up, this process is all about being realistic. Sometimes, you’ve got to use quick fixes to get things done on time, and that’s okay. It helps by keeping these quick and dirty bits of code in one spot, so your main code stays maintainable. It’s not about feeling bad for using these shortcuts; it’s about being clear and honest about them.

ⓘ shame.css concept was introduced by Harry Roberts. 
Read more: Keeping track of your hacks