The 1960s idea of “appropriate technology” feels like an early version of the principle of least power.
Tuesday, April 27th, 2021
Sunday, April 18th, 2021
New technologies don’t have power; for that they’d need a community, documentation, and a thriving ecosystem of ancillary technology. What they have is potential, which resonates with the potential within the startup and the early adopter; perhaps they can all, over time, grow together.
This means startups don’t adopt new technologies despite their immaturity, they adopt them because of that immaturity. This drives a constant churn of novelty and obsolescence, which amplifies the importance of a technologist’s skillset, which drives startups to adopt new technologies.
This flywheel has been spinning for a long time, and won’t stop simply because I’ve pointed out that we’re conflating novelty with technological advancement. Hopefully we can slow it down, though, because I believe it’s causing real harm.
Saturday, April 3rd, 2021
Principles and the English language
One of my roles at Clearleft is “content buddy.” If anyone is writing a talk, or a blog post, or a proposal and they want an extra pair of eyes on it, I’m there to help.
I think a lot about design principles for the web. The two principles I keep coming back to are the robustness principle and the principle of least power.
When it comes to words, the guide that I return to again and again is George Orwell, specifically his short essay, Politics and the English Language.
Towards the end, he offers some rules for writing.
- Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
- Never use a long word where a short one will do.
- If it is possible to cut a word out, always cut it out.
- Never use the passive where you can use the active.
- Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
- Break any of these rules sooner than say anything outright barbarous.
These look a lot like design principles. Not only that, but some of them look like specific design principles. Take the robustness principle:
Be conservative in what you send, be liberal in what you accept.
That first part applies to Orwell’s third rule:
If it is possible to cut a word out, always cut it out.
Be conservative in what words you send.
Then there’s the principle of least power:
Choose the least powerful language suitable for a given purpose.
Compare that to Orwell’s second rule:
Never use a long word where a short one will do.
That could be rephrased as:
Choose the shortest word suitable for a given purpose.
Or, going in the other direction, the principle of least power could be rephrased in Orwell’s terms as:
Never use a powerful language where a simple language will do.
Oh, I like that! I like that a lot.
Wednesday, March 17th, 2021
I really like the approach that Carie takes here. Instead of pointing to specific patterns to use, she provides a framework for evaluating technology. Solutions come and go but this kind of critical thinking is a long-lasting skill.
Monday, January 25th, 2021
You catch more flies with honey than Tailwind.
Monday, January 18th, 2021
The juxtaposition of The HTTP Archive’s analysis and The State of JS 2020 Survey results suggest that a disproportionately small—yet exceedingly vocal minority—of white male developers advocate strongly for React, and by extension, a development experience that favors thick client/thin server architectures which are given to poor performance in adverse conditions. Such conditions are less likely to be experienced by white male developers themselves, therefore reaffirming and reflecting their own biases in their work.
Wednesday, December 9th, 2020
Chris is gathering end-of-year thoughts from people in response to the question:
What is one thing you learned about building websites this year?
Friday, October 16th, 2020
Friday, July 31st, 2020
Recreating Wildlife Photographer of the Year online – part 1 – Introduction and technical approach – Blogs from the Natural History Museum
Now here’s the story from the team that made the website. It’s a great walkthrough of thoughtfully evaluating technologies to figure out the best approach.
Saturday, July 18th, 2020
A good explanation of the hydration problem in tools like Gatsby.
Wednesday, July 1st, 2020
Smart thoughts from Ethan on how design systems can cement your existing ways of working, but can’t magically change how collaboration works at your organisation.
Modern digital teams rarely discuss decisions in terms of the collaborative costs they incur. It’s tempting—and natural!—to see design- or engineering-related decisions in isolation: that selecting Vue as a front-end framework only impacts the engineering team, or that migrating to Figma only impacts designers. But each of these changes the way that team works, which impacts how other teams will work and collaborate with them.
Thursday, June 25th, 2020
I’m very selective about how I depend on other people’s work in my personal projects. Here are the factors I consider when evaluating dependencies.
- Complexity How complex is it, who absorbs the cost of that complexity, and is that acceptable?
- Comprehensibility Do I understand how it works, and if not, does that matter?
- Reliability How consistently and for how long can I expect it to work?
I really like Rob’s approach to choosing a particular kind of dependency when working on the web:
When I’m making things, that’s how I prefer to depend on others and have them depend on me: by sharing strong, simple ideas as a collective, and recombining them in novel ways with rigorous specificity as individuals.
Wednesday, May 13th, 2020
Ultimately, however, our decision to switch was driven by our difficulty in hiring new talent for $UNREMARKABLE_LANGUAGE, despite it being taught in dozens of universities across the United States. Our blog posts on $PRACTICAL_OPEN_SOURCE_FRAMEWORK seemed to get fewer upvotes when posted on Reddit as well, cementing our conviction that our technology stack was now legacy code.
This is all just mwah—chef’s kiss!—perfect:
Every metric that matters to us has increased substantially from the rewrite, and we even identified some that were no longer relevant to us, such as number of bugs, user frustration, and maintenance cost.
Monday, March 30th, 2020
Over the past few years, I’ve given quite a few workshops and talks on evaluating technology. This methodical approach to evaluation and prioritisation from Trys is right up my alley!
In any development project, there is a point at which one must decide on the tech stack. For some, that may feel like a foregone conclusion, dictated by team appetite and experience.
Even if the decision seems obvious, it’s always worth sense-checking your thought process. Along with experience and gut-feelings, we also have blind-spots and biases.
I feel like there’s a connection here to having good design principles—the kind that explicitly value one facet over another.
Wednesday, February 26th, 2020
Lessons for web development from a home renovation project:
- Greenfield Projects Are Everyone’s Favorite
- The Last Person’s Work Is Always Bewildering
- It’s All About the Trade-Offs
- It ALWAYS Takes Longer Than You Think
- Communication, Communication, Communication!
And there’s this:
You know those old homes people love because they’re unique, have lasted for decades, and have all that character? In contrast, you have these modern subdivision homes that, while shiny and new, are often bland and identical (and sometimes shoddily built).
node_modulesis like the suburbia/subdivision of modern web development: it seems nice and fancy today, and most everyone is doing it, but in 30 years everyone will hate the idea. They’ll all need to be renovated or torn down. Meanwhile, the classical stuff that’s still standing from 100 years ago lives on but nobody seems to be building houses that way anymore for some reason. Similarly, the first website ever is still viewable in all modern web browsers. But many websites built last year on last year’s bleeding edge tech already won’t work in a browser.
Wednesday, November 20th, 2019
I’m really enjoying this end-of-the-year round-up from people speaking their brains. It’s not over yet, but there’s already a lot of thoughtful stuff to read through.
Only a few years ago, I would need a whole team of developers to accomplish what can now be done with just a few amazing tools.
And I like this zinger from Geoff:
What you need to build a great website is restraint.
Thursday, August 8th, 2019
I recently wrote about a web-specific example of a general principle for choosing the right tool for the job:
I was—yet again—talking about appropriateness. Use the right technology for the task at hand. Here’s the example I gave:
Surprisingly, I got some pushback on this. Šime Vidas wrote:
Based on my experience, this is not necessarily the case.
Going from server-side rendering and progressive enhancement via JS to a single-page app powered by a JS framework was a enormous reduction in complexity for me (so the opposite of over-engineering).
(Emphasis mine.) He goes on to say:
My main concerns are ease of use & maintainability. If you get those things right, you’re good and it’s not over-engineering.
There’s no doubt that maintainability is a desirable goal. And ease of use for the developer is also important …but I think they pale in comparison to ease of use for the end user.
To be fair, the specific use-case I mentioned was making a blog. And a blog is a personal thing. You can do whatever the heck you like on your own website and don’t let anyone tell you otherwise.
So I probably chose a poor example to illustrate my point. I was thinking more about when you’re making websites for a living. You’re being paid money to make something available on the web. In that situation, I strongly believe that user needs should win out over developer convenience.
As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time.
That’s why I responded to Šime, saying:
Your main concern should be user needs—not your own.
When I talk about over-engineering, I’m speaking from the perspective of end users, not developers.
Before considering your ease of use, and maintainability, consider users first.
In fairness to Šime, he’s being very open and honest about his priorities. I admire that. I’ve seen too many developers try to provide user experience justifications for decisions made for developer convenience. Once again I recommend Alex’s excellent article, The “Developer Experience” Bait-and-Switch:
The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.
Now I worry I wasn’t specific enough when I talked about choosing appropriate technology:
Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand.
I should have made it clear that I was talking about what is appropriate or inapropriate for users. I think I made the mistake of assuming that this was obvious, and didn’t need saying. I’ll try not to make that mistake again.
If you’re in that situation—you are being paid money to make websites, and you are making technology decisions—I urge you to remember Charlie’s words: it isn’t about you.
Wednesday, July 31st, 2019
Charlie’s thoughts on dev perception:
People speak about “the old guard” and “stupid backwards techniques”, forgetting that it’s real humans, with real constraints who are working on these solutions. Most of us are working in a “stupid backwards way” because that “backwardsness” WORKS. It is something that is proven and is clearly documented. We can implement it confident that it will not disappear from fashion within a couple of years.
Thursday, July 25th, 2019
My main concern about this new generation of tools is that they require a specific toolchain in order to function. “If you just use this version of React and just use this styling library and configure things in exactly this way, your designers can play around with coded components.” It worries me that teams would end up choosing (and subsequently holding onto) specific tools not because they’re the best choices for our users but because the designers’ and developers’ workflow depends on a specific toolchain to work properly.
You can spot the less useful design principles after a while. They tend to be wishy-washy; more like empty aspirational exhortations than genuinely useful guidelines for alignment. I’ve written about what makes for good design principles before. Matthew Ström also asked—and answered—What makes a good design principle?
- Good design principles are memorable.
- Good design principles help you say no.
- Good design principles aren’t truisms.
- Good design principles are applicable.
I like those. They’re like design principles for design principles.
One set of design principles that I’ve included in my collection is from gov.uk: government design principles . I think they’re very well thought-through (although I’m always suspicious when I see a nice even number like 10 for the amount of items in the list). There’s a great line in design principle number two—Do less:
Government should only do what only government can do.
This wasn’t a theoretical issue. The multiple departmental websites that preceded gov.uk were notorious for having too much irrelevant content—content that was readily available elsewhere. It was downright wasteful to duplicate that content on a government site. It wasn’t appropriate.
I think that the design principle from GDS could be abstracted into a general technology principle:
Any particular technology should only do what only that particular technology can do.
Choose the least powerful language suitable for a given purpose.
Or, as Derek put it:
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.
ARIA should only do what only ARIA can do.
CSS should only do what only CSS can do.
HTML should only do what only HTML can do.