Tags: maintainability

28

sparkline

Tuesday, November 13th, 2018

Tweeting for 10,000 Years: An Experiment in Autonomous Software — Brandur Leach

Taking the idea of the Clock of the Long Now and applying it to a twitterbot:

Software may not be as well suited as a finely engineered clock to operate on these sorts of geological scales, but that doesn’t mean we can’t try to put some of the 10,000 year clock’s design principles to work.

The bot will almost certainly fall foul of Twitter’s API changes long before the next tweet-chime is due, but it’s still fascinating to see the clock’s principles applied to software: longevity, maintainability, transparency, evolvability, and scalability.

Software tends to stay in operation longer than we think it will when we first wrote it, and the wearing effects of entropy within it and its ecosystem often take their toll more quickly and more destructively than we could imagine. You don’t need to be thinking on a scale of 10,000 years to make applying these principles a good idea.

Sunday, November 4th, 2018

When your design system fails — HeyDesigner

You could create components that strike the perfect balance between reuse and context sensitivity. But defining the components of your design system is just the first step. It has to make its way into the product. If it doesn’t, a design system is like a language with no extant literature or seminal texts.

Marissa Christy outlines the reasons why your design system might struggle:

  1. The redesign isn’t prioritized
  2. The tech stack is changing
  3. Maintenance takes discipline

But she also offers advice for counteracting these forces:

  1. Get buy-in from the whole team
  2. Prioritize a lightweight re-skin on older parts of the product
  3. Treat a design system like any other product project: start small
  4. Don’t wait for others. Lead by example.
  5. Finally, don’t compare yourself to others on the internet

Monday, October 8th, 2018

Sass Selectors: To Nest Or Not To Nest? | Brad Frost

The fascinating results of Brad’s survey.

Personally, I’m not a fan of nesting. I feel it obfuscates more than helps. And it makes searching for a specific selector tricky.

That said, Danielle feels quite strongly that nesting is the way to go, so on Clearleft projects, that’s how we write Sass + BEM.

Friday, September 28th, 2018

What is Modular CSS?

A walk down memory lane, looking at the history modular CSS methodologies (and the people behind them):

Wednesday, November 8th, 2017

The Art of Comments | CSS-Tricks

Great advice on writing sensible comments in your code.

Wednesday, November 1st, 2017

Rebuilding slack.com – Several People Are Coding

A really great case study of a code refactor by Mina, with particular emphasis on the benefits of CSS Grid, fluid typography, and accessibility.

Saturday, August 12th, 2017

I made a style guide for my personal web site and you should too.—zachleat.com

Here’s Zach’s style guide. But the real reason I’m linking to this is his lovely description of having a personal website that grows over time:

As my own little corner of the web unceremoniously turned ten years old this year, it’s really starting to feel more like a garden than a piece of software. I certainly enjoy tending to it. I can plant what I like and with proper care it can grow into something useful.

Thursday, June 22nd, 2017

Oh No! Our Stylesheet Only Grows and Grows and Grows! (The Append-Only Stylesheet Problem) | CSS-Tricks

I think Chris is on to something here when he identifies one of the biggest issues with CSS growing out of control:

The developers are afraid of the CSS.

Thursday, November 24th, 2016

Between the braces

In a post called Side Effects in CSS that he wrote a while back, Philip Walton talks about different kinds of challenges in writing CSS:

There are two types of problems in CSS: cosmetic problems and architectural problems.

The cosmetic problems are solved by making something look the way you want it to. The architectural problems are trickier because they have more long-term effects—maintainability, modularity, encapsulation; all that tricky stuff. Philip goes on to say:

If I had to choose between hiring an amazing designer who could replicate even the most complicated visual challenges easily in code and someone who understood the nuances of predictable and maintainable CSS, I’d choose the latter in a heartbeat.

This resonates with something I noticed a while back while I was doing some code reviews. Most of the time when I’m analysing CSS and trying to figure out how “good” it is—and I know that’s very subjective—I’m concerned with what’s on the outside of the curly braces.

selector {
    property: value;
}

The stuff inside the curly braces—the properties and values—that’s where the cosmetic problems get solved. It’s also the stuff that you can look up; I certainly don’t try to store all possible CSS properties and values in my head. It’s also easy to evaluate: Does it make the thing look like you want it to look? Yes? Good. It works.

The stuff outside the curly braces—the selectors—that’s harder to judge. It needs to be evaluated with lots of “what ifs”: What if this selects something you didn’t intend to? What if the markup changes? What if someone else writes some CSS that negates this?

I find it fascinating that most of the innovation in CSS from the browser makers and standards bodies arrives in the form of new properties and values—flexbox, grid, shapes, viewport units, and so on. Meanwhile there’s a whole other world of problems to be solved outside the curly braces. There’s not much that the browser makers or standards bodies can do to help us there. I think that’s why most of the really interesting ideas and thoughts around CSS in recent years have focused on that challenge.

Wednesday, November 23rd, 2016

CSS Inheritance, The Cascade And Global Scope: Your New Old Worst Best Friends – Smashing Magazine

A really terrific piece by Heydon that serves as a rousing defence of the cascade in CSS. It’s set up in opposition to methodologies like BEM (and there’s plenty of back’n’forth in the comments), but the truth is that every project is different so the more approaches you have in your toolkit, the better. For many projects, something like BEM is a good idea. For others, not so much.

Funnily enough, I’ve been working something recently where I’ve been embracing the approach that Heydon describes—although, to be fair, it’s a personal project where I don’t have to think about other developers touching the HTML or CSS.

Sunday, October 23rd, 2016

On Style Maintenance | CSS-Tricks

This is a very thoughtful analysis of different approaches to writing maintainable CSS, which—let’s face it—is the hard bit.

I often joke that I don’t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.

I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews.

Also, can I just say how refreshing it is to read an article that doesn’t treat the cascade like a disease to be wiped out? This article even goes so far as to suggest that the cascade might actually be a feature—shock! horror!

The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you’re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces.

There’s a lot of really good stuff in here to mull over.

My hope for this article is to encourage developers to think ahead. We’re all in this together, and the best we can do is learn from one another.

Monday, October 10th, 2016

Dan McKinley :: Choose Boring Technology

A somewhat contentious title but there’s some really smart thinking here about choosing and evaluating technology.

The slidedeck version is even clearer.

Tuesday, August 9th, 2016

Refactoring CSS Without Losing Your Mind // Speaker Deck

A talk from Harry on the whys and hows of refactoring CSS. He mentions the all: initial declaration, which I don’t think I’ve come across before.

Thursday, May 26th, 2016

Semantic CSS - Snook.ca

Snook has been on a roll lately, sharing lots of great insights into front-end development. This is a particularly astute post about that perennial issue of naming things.

Thursday, January 29th, 2015

What we would change about Rizzo - Ian Feather

I really like the self-examination that Ian and his team at Lonely Planet are doing here. Instead of creating a framework for creating a living style guide and calling it done, they’re constantly looking at what could be done better, and revisiting earlier decisions.

I’m intrigued by the way they’ve decided to reorganise their files by component rather than by filetype.

Friday, January 2nd, 2015

CSS: Just Try and Do a Good Job

Good advice from Chris, particularly if you’re the one who has to live with the CSS you write.

As Obi-Wan Kenobi once said, “You must do what you feel is right, of course.”

Tuesday, August 19th, 2014

CSS Guidelines – High-level advice and guidelines for writing sane, manageable, scalable CSS

Harry has written down his ideas and recommendations for writing CSS.

Monday, July 28th, 2014

A Maintainable Style Guide - Ian Feather

The challenges of maintaining a living breathing front-end style guide for an always-evolving product (the Lonely Planet website in this case).

GitHub’s CSS · @mdo

Mark Otto talks through the state of Github’s CSS and the processes behind updating it. There’s a nice mix of pragmatism and best practices, together with a recognition that there’s always room for improvement.

Tuesday, June 24th, 2014

Permanence - Matt Gemmell

Some good ideas from Matt on the importance of striving to maintain digital works. I find it very encouraging to see other people writing about this, especially when it’s this thoughtful.