We need engineers, we need designers, and we absolutely need design engineers to make that connection across the great divide between the front-of-the-front-end and the back-of-the-front-end. It’s only then that we can make truly great things together.
The right coding language, system architecture, or interface design will vary wildly from project to project. But there are characteristics particular to software that consistently cause traditional management practices to fail, while allowing small startups to succeed with a shoestring budget:
- Reusing good software is easy; it is what allows you to build good things quickly;
- Software is limited not by the amount of resources put into building it, but by how complex it can get before it breaks down; and
- The main value in software is not the code produced, but the knowledge accumulated by the people who produced it.
Understanding these characteristics may not guarantee good outcomes, but it does help clarify why so many projects produce bad outcomes. Furthermore, these lead to some core operating principles that can dramatically improve the chances of success:
- Start as simple as possible;
- Seek out problems and iterate; and
- Hire the best engineers you can.
I’m glad I have this site to play with things, almost all web development and ‘front-end’ stuff leaves me cold these days. It’s all so process driven, so full of unnecessary complexities and dependencies, it’s as if the entire industry wants you to forget you can write HTML by hand and upload it somewhere and it’s a working website. It’s complexity for complexity’s sake, like what accountancy software companies did to the tax code: “Oh this is too complex you need to pay us lots of money to sort it out.” Annoying. I can see some resistance to it and there are still people making blogs and playing around with stuff, so hopefully the professional professionals will calm the fuck down at some point.
So my little mashup, which was supposed to be just 3 technologies ended up exposing me to ~20 different technologies and had me digging into nth-level dependency source code after midnight.
The technologies within technologies that Dave lists here is like emptying a bag of scrabble pieces.
The “modern” web stack really is quite something—we’ve done an amazing job of taking relatively straightforward tasks and making them complicated, over-engineered, and guaranteed to be out of date in no time at all.
The plumbing and glue code are not my favorite parts of the job. And often, you don’t truly know the limitations of any given dependency until you’re five thousand lines of code into a project. Massive sunk costs and the promise of rapid application development can come screeching to a halt when you run out of short cuts.
Trys ponders home repair projects and Postel’s Law.
As we build our pages, components, and business logic, establish where tolerance should be granted. Consider how flexible each entity should be, and on what axis. Determine which items need to be fixed and less tolerant. There will be areas where the data or presentation being accurate is more important than being flexible - document these decisions.
This is about seamful design.
We need to know things better if we want to be better.
It’s also about progressive enhancement.
Highly sophisticated systems work flawlessly, as long as things go as expected.
When a problem occurs which hasn’t been anticipated by the designers, those systems are prone to fail. The more complex the systems are, the higher are the chances that things go wrong. They are less resilient.
A good explanation of the hydration problem in tools like Gatsby.
I wrote something recently about telling the story of performance. Sue Loh emphasis the importance of understanding what makes people tick:
Performance engineers need to be an interesting mix of data-lovers and people-whisperers.
As a resident of Brighton—home to the most beautiful of bandstands—this bit of background to their history is fascinating.
This is a great piece! It starts with a look back at some of the great minds of the nineteenth century: Herschel, Darwin, Babbage and Lovelace. Then it brings us, via JCR Licklider, to the present state of the web before looking ahead to what the future might bring.
So what will the life of an interface designer be like in the year 2120? or 2121 even? A nice round 300 years after Babbage first had the idea of calculations being executed by steam.
I think there are some missteps along the way (I certainly don’t think that inline styles—AKA CSS in JS—are necessarily a move forwards) but I love the idea of applying chaos engineering to web design:
Think of every characteristic of an interface you depend on to not ‘fail’ for your design to ‘work.’ Now imagine if these services were randomly ‘failing’ constantly during your design process. How might we design differently? How would our workflows and priorities change?
Take a tour of the Lunar Module.
The LM (or “LEM”, as it’s pronounced) has the appearance of an aeronautical joke, with not a trace of streamlining. Instead, it’s an insect-like asymmetrical collection of legs, angles, bulges, and surfaces that’s very hard to visualize. Frankly, it looks like it was thrown together on a Friday afternoon by someone in a hurry to go fishing.
This article by Ian Bogost from a few years back touches on one of the themes in the talk I gave at New Adventures:
“Engineer” conjures the image of the hard-hat-topped designer-builder, carefully crafting tomorrow. But such an aspiration is rarely realized by computing. The respectability of engineering, a feature built over many decades of closely controlled, education- and apprenticeship-oriented certification, becomes reinterpreted as a fast-and-loose commitment to craftwork as business.
Let’s take a meandering waltz through what other people have to say about simplicity.
Ah, what a wonderful treasure trove this is! PDF scans of Apollo era press kits from a range of American companies.
- Official NASA
- Lunar Module
There’s something so fascinating about the mundane details of Isolation/Quarantine Foods for Apollo 11 Astronauts from Stouffer’s.
Tales of over-engineering, as experienced by Bridget. This resonates with me, and I think she’s right when she says that these things go in cycles. The pendulum always ends up swinging the other way eventually.
This is a perceptive overview of three different species of agencies—consulting-led, engineering-led, and design-led. Clearleft fits squarely into that last category …and the weaknesses of that particular flavour of agency ring very true:
Design firms have historically lacked the business strategy chops and pedigree of the consultants.
It will probably come as no surprise that Clearleft has been getting “more strategic” recently.
Design needs more MBAs with C-suite relationships and an almost arrogant assumption that of course they belong there, advising the CEO and truly bringing design thinking to business. It’s time to do strategy for real. The market has never been more receptive to it than it is right now.