LLMs are useful when you need a compromise between fast and good. You will never get a good outcome fast.
I’m afraid we are settling into a status of good enough when using “AI,” which is especially hurtful for accessibility.
There’s quite a crossover between resilience and longevity:
- Understand the requirements
- Keep scope small and fixed
- Reduce dependencies
- Produce static output
- Increase Quality Assurance
I’ve worked in the tech industry for close to two decades at this point. I’ve seen how difficult it is to build quality products, but I’ve also seen that it can be done. It just feels like no one gives a shit anymore, beyond a handful of independent devs and small shops. It’s wild.
I’ve personally struggled to implement a decentralized approach to quality in many of my teams. I believe in it from an academic standpoint, but in practice it works against the grain of every traditional management structure. Managers want ‘one neck to wring’ when things go wrong. Decentralized quality makes that impossible. So I’ve compromised, centralized, become the bottleneck I know slows things down. It’s easier to defend in meetings. But when I’ve managed to decentralize quality — most memorably when I was running a small agency and could write the org chart myself — I’ve been able to do some of the best work of my career.
AI is, of course, at the center of this moment. It’s a mediocrity machine by default, attempting to bend everything it touches toward a mathematical average. Using extraordinary amounts of resources, it has the ability to create something good enough, a squint-and-it-looks-right simulacrum of normality. If you don’t care, it’s miraculous.
In the Who Cares Era, the most radical thing you can do is care.
In a moment where machines churn out mediocrity, make something yourself. Make it imperfect. Make it rough. Just make it.
I’m going to share this with the organisers of that conference I pulled out of recently.
When I was looking back at 2024, I mentioned that I didn’t give a single conference talk (though I did host three conferences—Patterns Day, CSS Day, and UX London).
I almost spoke at a conference though. I was all set to speak at an event in the Netherlands. But then the line-up was announced and I was kind of shocked at the lack of representation. The schedule was dominated by white dudes like me. There were just four women in a line-up of 30 speakers.
When I raised my concerns, I was told:
We did receive a lot of talks, but almost no women because there are almost no women in this kind of jobs.
Yikes! I withdrew my participation.
I wish I could say that it was one-off occurrence, but it just happened again.
I was looking forward to speaking at DevDays Europe. I’ve never been to Vilnius but I’ve heard it’s lovely.
Now, to be fair, I don’t think the line-up is finalised, but it’s not looking good.
Once again, I raised my concerns. I was told:
Unfortunately, we do not get a lot of applications from women and have to work with what we have.
Even though I knew I was just proving Brandolini’s law, I tried to point out the problems with that attitude (while also explaining that I’ve curated many confernce line-ups myself):
It’s not really conference curation if you rely purely on whoever happens to submit a proposal. Surely you must accept some responsibility for ensuring a good diverse line-up?
The response began with:
I agree that it’s important to address the lack of diversity.
…but then went on:
I just wanted to share that the developer field as a whole tends to be male-dominated, not just among speakers but also attendees.
At this point, I’m face-palming. I tried pointing out that there might just be a connection between the make-up of the attendees and the make-up of the speaker line-up. Heck, if I feel uncomfortable attending such a homogeneous conference, imagine what a woman developer would think!
Then they dropped the real clanger:
While we always aim for a diverse line-up, our main focus has been on ensuring high-quality presentations and providing the best experience for our audience.
Double-yikes! I tried to remain calm in my response. I asked them to stop and think about what they were implying. They’re literally setting up a dichotomy between having a diverse line-up and having a good line-up. Like it’s inconceivable you could have both. As though one must come at the expense of the other. Just think about the deeply embedded bias that would enable that kind of worldview.
Needless to say, I won’t be speaking at that event.
This is depressing. It feels like we’re backsliding to what conferences were like 15 years ago.
I can’t help but spot the commonalaties between the offending events. Both of them have multiple tracks. Both of them have a policy of not paying their speakers. Both of them seem to think that opening up a form for people to submit proposals counts as curation. It doesn’t.
Don’t get me wrong. Having a call for proposals is great …as long as it’s part of an overall curation strategy that actually values diversity.
You can submit a proposal to speak at FFconf, for example. But Remy doesn’t limit his options to what people submit. He puts a lot of work into creating a superb line-up that is always diverse, and always excellent.
By the way, you can also submit a proposal for UX London. I’ve had lots of submissions so far, but again, I’m not going to limit my pool of potential speakers to just the people who know about that application form. That would be a classic example of the streetlight effect:
The streetlight effect, or the drunkard’s search principle, is a type of observational bias that occurs when people only search for something where it is easiest to look.
It’s quite depressing to see this kind of minimal-viable conference curation result in such heavily skewed line-ups. Withdrawing from speaking at those events is literally the least I can do.
What I’m looking for: at least 40% of speakers have to be women speaking on the subject of their expertise instead of being invited to present for the sake of adjusting the conference quotas. I want to see people of colour too. In an ideal scenario, I’d like to see as many gender identities, ethnical backgrounds, ages and races as possible.
I’ve always maintained that prototyping and production require different mindsets. Trys suggests it’s not as simple as that.
I agree with much of what he says about back-end decisions (make it manual ‘till it hurts—avoid premature optimisation), but as soon as you’re delivering HTML, CSS, and JavaScript to real people, I think you need to meet certain standards when it comes to accessibility, performance, etc.
I know that the number one cause of jank and breakage is another developer having messed with the browser’s default way of doing things.
THIS!!! A thousand times, THIS!
When I came up with this, it was specifically about bad software that seems good enough. Usually, stakeholders are less willing to invest in a good solution when one already exists.
Vasilis gives the gist of his excellent talk at the border:none event that just wrapped up in Nuremberg. The rant at the end chimed very much with my feelings on this topic:
I showed a little interaction experiment that one of my students made, with incredible attention to detail. Absolutely brilliant in so many ways. You would expect that all design agencies would be fighting to get someone like that into their design team. But to my amazement she now works as a react native developer.
I have more of these very talented, very creative designers who know how to code, who really understand how the web works, who can actually design things for the web, with the web as a medium, who understand the invisible details, who know about the UX of HTML, who know what’s possible with modern HTML and CSS. Yet when they start working they have to choose: you either join our design team and are forced to use a tool that doesn’t get it, or you join the development team and are forced to use a ridiculous framework and make crap.
If you look at the available evidence, “craft at scale” is mutually exclusive with the kind of rapid and unending growth that’s the baseline expectation for traditional startups and public tech companies.
We’d say that’s obvious in other industries. Budweiser isn’t craft beer. IKEA isn’t heirloom-quality furniture. But we tend to treat software as immune to the typical relationship between quality and quantity.
The story that “artificial intelligence” tells is a smoke screen. But smoke offers only temporary cover. It fades if it isn’t replenished.
I often use the word quality when referring to apps, products and services I hold in a high regard but another word that often comes up in this context is craft. Craft, as in something that is handcrafted where something someone spent a lot of time on and maybe even embedded their own personal touches and personality in it. Often something handcrafted feels more premium.
Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.
This talks about development, but I believe it applies equally—if not more—to design.
And this is very insightful:
Instead of spending tons of time and effort on hiring because you believe that you can “only hire the best”, direct some of that effort towards building a system that produces great results out of a wider spectrum of individual performance.
If you’re travelling around Ireland, you may come across some odd pieces of 19th century architecture—walls, bridges, buildings and roads that serve no purpose. They date back to The Great Hunger of the 1840s. These “famine follies” were the result of a public works scheme.
The thinking went something like this: people are starving so we should feed them but we can’t just give people food for nothing so let’s make people do pointless work in exchange for feeding them (kind of like an early iteration of proof of work for cryptobollocks on blockchains …except with a blockchain, you don’t even get a wall or a road, just ridiculous amounts of wasted energy).
This kind of thinking seems reprehensible from today’s perspective. But I still see its echo in the work ethic espoused by otherwise smart people.
Here’s the thing: there’s good work and there’s working hard. What matters is doing good work. Often, to do good work you need to work hard. And so people naturally conflate the two, thinking that what matters is working hard. But whether you work hard or not isn’t actually what’s important. What’s important is that you do good work.
If you can do good work without working hard, that’s not a bad thing. In fact, it’s great—you’ve managed to do good work and do it efficiently! But often this very efficiency is treated as laziness.
Sensible managers are rightly appalled by so-called productivity tracking because it measures exactly the wrong thing. Those instruments of workplace surveillance measure inputs, not outputs (and even measuring outputs is misguided when what really matters are outcomes).
They can attempt to measure how hard someone is working, but they don’t even attempt to measure whether someone is producing good work. If anything, they actively discourage good work; there’s plenty of evidence to show that more hours equates to less quality.
I used to think that must be some validity to the belief that hard work has intrinsic value. It was a position that was espoused so often by those around me that it seemed a truism.
But after a few decades of experience, I see no evidence for hard work as an intrinsically valuable activity, much less a useful measurement. If anything, I’ve seen the real harm that can be caused by tying your self-worth to how much you’re working. That way lies burnout.
We no longer make people build famine walls or famine roads. But I wonder how many of us are constructing little monuments in our inboxes and calendars, filling those spaces with work to be done in an attempt to chase the rewards we’ve been told will result from hard graft.
I’d rather spend my time pursuing the opposite: the least work for the most people.
Though I didn’t make the connection until much later, the philosophy of progressive enhancement in web design, which I’ve been advocating for nearly two decades now, is very much the embodiment of equity. It’s concerned with building interfaces that adapt to a wide range of circumstances, both tied to an individual user’s capabilities as well as those of the devices, networks, and environment in which they are accessing our creations.
Speed for the sake of speed means nothing. If our design systems don’t ultimately lead to better quality experiences, we’re doing it wrong.
When we rush to release one-size-fits-all components, without doing the work to understand different contexts before curating and consolidating solutions, we sacrifice quality at the hands of speed.
The irony? In the long run, this will slow us down. We end up having to undo the work we’ve done to fix the problems we’ve created.
Ultimately, when we prioritise speed over quality, we end up with neither.
Baldur Bjarnason writes an immense treatise on the current sad state of software, grounded in the historical perspective of the past sad state of software.