Number one:
Do things in the most straightforward way possible. It’s easy to fall into the trap of clever solutions, or clever applications of technology, or overbuilding something because you’re anticipating the future. Don’t do it. You will hate yourself for it later when you have to maintain it.
People act like writing code is the hard part of software. It is not. It never has been, it never will be. Writing code is the easiest part of software engineering, and it’s getting easier by the day. The hard parts are what you do with that code—operating it, understanding it, extending it, and governing it over its entire lifecycle.
The present wave of generative AI tools has done a lot to help us generate lots of code, very fast. The easy parts are becoming even easier, at a truly remarkable pace. But it has not done a thing to aid in the work of managing, understanding, or operating that code. If anything, it has only made the hard jobs harder.
A very thought-provoking presentation from Maggie on how software development might be democratised.
An insightful and incisive appraisal of technology adoption. This truth hits hard:
React and the component model standardises the software developer and reduces their individual bargaining power excluding them from a proportional share in the gains. Its popularity among executives and management is entirely down to the fact that it helps them erase the various specialities – CSS, accessibility, standard JavaScript in the browser, to name a few – from the job market. Those specialities might still exist in practice – as ad hoc and informal requirements during teamwork – but, as far as employment is concerned, they’re such a small part of the overall developer job market that they might as well be extinct.
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.
Warm-blooded software:
Maybe your CI isn’t working because one of the services you depend on got bought or ran out of money. You add a new dependency and find yourself needing to upgrade your compiler. Another package you depend on is deprecated, and doesn’t work with the latest version of the compiler.
I aspire to build cold-blooded software:
You work alone, make some changes when you’re inspired, and then don’t touch it again for another year, or two, or three.
This is a handy little tool for spinning up a local web server when you don’t all the features of something like MAMP.
I love, love, love the deep thinking that Lea has put into this, really digging into the guts of what design does.
Overfitting happens when solutions don’t generalize sufficiently and is a hallmark of poor design. Eigensolutions are the opposite: solutions that generalize so much they expose links between seemingly unrelated use cases. Designing eigensolutions takes a mindset shift from linear design to composability.
Lea ties this into web standards too. It’s really helped clarify for me why I want more declarative options for common use cases (like a share button)—it’s about raising the ceiling without raising the floor.
A terrific piece from Aaron Sankin that goes from Waldsterben to software development via firefighting and the RAND corporation.
Bureaucracies use measurements to optimize and rearrange the world around them. For those measurements to be effective, they have to be conducted in units as relevant as possible to the conditions on the ground.
I’d like to suggest that everybody in web dev point their dysfunctional novelty seeking (of which I suffer as well) in the direction of HTML and CSS. See how much can be done without JavaScript. It’s a lot! Then look at writing more lightweight JavaScript that’s layered on top of the HTML as enhancements. Because it’s an enhancement and not required for functionality, you can cut the line higher and use newer tech without worry.
See how refreshing that feels.
Pirijan talks us through the design principles underpinning Kinopio, a tool I like very much:
- Embrace Smallness by Embracing Code as a Living Design System
- Building for Fidget-Ability, hmmm
- Embrace Plain Text
- A Single Interface for Mobile and Desktop
- Refine by Pruning
Past some point, making a system more efficient will mean making it less resilient, and, conversely, building in robustness tends to make a system less efficient (at least in the short run).
This is true of software, networks, and organisations.
When we set metrics or goals for a system or a team or an organization that ask for efficiency, let us be aware that, absent countervailing pressures, we are probably also asking for the system to become more brittle and fragile, too.
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.
Same:
Opening up my RSS reader, a cup of coffee in hand, still feels calm and peaceful in a way that trying to keep up with happenings in other ways just never has.
Talking primarily to engineering leaders, but also CEOs, VCs, ICs, and other practitioners, the most common response to the question of “has something substantially changed?” is that software, counter intuitively, has gotten harder to build. This is counter intuitive because the tools are orders of magnitude better, the amount of work you can cheaply outsource is nearly miraculous, computers are so damn fast and cheap these days, the quality of resources, much of it free, is off the charts, and the talent pool has exploded, and shows every sign of being smarter and better educated than ever. But software has gotten harder to build in one very particular and important way: it’s gotten more complex.
Kellan nails it:
We’ve developed an aesthetics of complexity: the sense that a good system is a complex one, that you should prefer a SPA over a web page, a distributed system over a simple one, a service over a config file, the idea if you aren’t on the latest technology you’re wasting your time, and potentially damaging your career.
This extract from Baldur’s new book is particularly timely in light of the twipocalypse.
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.
At Clarity last week, I had the great pleasure of introducing and interviewing Linda Dong who spoke about Apple’s Human Interface Guidelines. I loved the way she looked at the history of the HIG from 1977 onwards. This collection of videos is just what I need to keep spelunking into the interfaces of the past:
A curated collection of HCI demo videos produced during the golden age from 1983-2002.
A beautiful meditation on Christopher Alexander by Claire L. Evans.
I wrote a while back about descriptive and prescriptive design systems—and a follow-up post—but I didn’t realise there was such a thing as descriptive and prescriptive engineering.