shame.css – full .net interview

Written by Harry Roberts on CSS Wizardry.

Since writing about shame.css last week, there has been a lot of buzz and discussion around it, which is great! Part of that was an interview I did with .net magazine about the idea. You can read the edited version of the interview over on the .net site and you can also read the whole, unabridged version right here:

Do you think there’s a tendency from some in the web industry to not be realistic about the need for (hopefully) short-term hacks to get sites working?

Yes, big time. If you work on a site/product that earns millions of pounds a year then any bugs, breakages, quirks et cetera need fixing as soon as possible; your product owner doesn’t care if your CSS is perfect (nor should they, really), they care that the site is up and functional and ticking over that revenue. Good code is important—and hacks are far from ideal—but to think you can always avoid hacks and short-term/quick fixes is naive.

With websites/products you need to keep certain people happy; when a client is breathing down your neck—or a feature is broken on live—then you need to make sure you’re keeping the right stakeholders happy. If you spend an hour writing a perfect fix for something you could have superficially fixed in two minutes then I’d say you’re keeping the wrong person happy (i.e. yourself).

Hacks are far from ideal, and it would be nice to avoid them where possible, but to say/believe you can always avoid hacks and quick fixes is, to repeat myself, very naive. I’ve worked on projects of varying sizes (from simple one-page marketing sites to in-house, continuous (i.e. years) projects that earn serious amounts of cash) and I will readily admit that the need for hacks increases fairly proportionately with the size of the project, but the good thing about that is that you’ll likely have more project time dedicated to fixing those hacks.

What would you consider ‘hacks’ in the context of shame.css? Would you treat cutting-edge CSS similarly, since that’s not always ‘clean’ or fully standardised, or is this just about botch-jobs that were needed to get something working and into production?

For me a hack is something that could have been done better given more time. It’s hard to think of examples out of context, but I think you’ll often know when something is a hack. Written something that you’d be ashamed to explain to a colleague? That’s probably a hack.

A hack is something where—as you’re writing it—you’re thinking there has to be a cleaner way to do this. Shame.css is about making a file full of things that you think you could have done better, a file that you can do better when you get the time to revisit it. It’s a self-writing todo list, really; a file of hacks that you put to one side to think about when you have more time.

On the documentation side of things, should people working on CSS get more into that in general, rather than just for hacks?

Yes! If there’s one thing all developers should do more, it’s writing comments. You should comment anything that isn’t immediately obvious from the code alone (comments like color:red; /* Makes the text red. */ are totally redundant). There’s nothing worse than picking up someone else’s code and wondering what anything does, or how, or why. Document your code so that, if you get hit by a bus on your way home, your colleague can take over right away the next day.

In terms of integration, do you essentially see the hacks appearing as a block of patches as the end of a minified CSS file? How would you recommend people work if they’re not using preprocessors?

If you are using a preprocessor then I’d @import the shame.[scss|less|etc] file right at the end, ideally (this could always lead to specificity and source-order problems, so your mileage may vary).

If you aren’t using a preprocessor but you do have a decent build process then all your CSS files should be concatenated and minified before they’re deployed anyway, so again, shame.css bolted onto the end of that.

If you aren’t using a preprocessor and you don’t have a build process then 1) you probably fix that and 2) I reckon a hacks section at the end of your stylesheet is probably your best bet. Shame.css isn’t at all intended for public viewing so you should never end up with a separate stylesheet called by a link element in your markup. You should be serving one concatenated and minified stylesheet only.

Finally, if shame.css as a concept really took off, how do you think it would change design process and websites in general?

Shame.css is only as useful as the developers who implement it. It’s all well and good isolating and documenting your hacks, but if you never fix or revisit them then you’re just in the same boat as before.

For me, shame.css signals a broader shift in development; it doesn’t need to be limited to CSS. The concept is merely ‘realising, documenting and making a point of your hacks’. You can apply that thinking to everything.

The real work involved with shame.css is getting your immediate team (developers) on board, and then making the business/PMs/scrum masters/BAs/product owners et cetera aware of the fact that their product will include less-than-ideal code sometimes, but that this code exists to meet business requirements.

Tell them that you are isolating and documenting these hacks and then get some development time allocated to tidy things up. It’s easier to make a business case for tidying up a codebase if you can quantify it; simply telling your project manager that I have some things to tidy up before I can move onto Feature X won’t always cut it. Take a list of things to your PM and try and get half a day of sprint time to spend cleaning up.

The idea behind shame.css is simply to make your hacks more transparent, quantifiable and isolated; it’s up to you what you do with that information.

By Harry Roberts

Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.

Did this help? We can do way more!