On Plain Old Boring HTML

And The Hubris of Disruption

, reading through my Rich Site Summary (RSS 🔍) feeds, I read The unreasonable effectiveness of simple HTML by Terence Eden.

If your laptop and phone both got stolen – how easily could you conduct online life through the worst browser you have? If you have to file an insurance claim online – will you get sent a simple HTML form to fill in, or a DOCX which won’t render?

What vital information or services are forbidden to you due to being trapped in PDFs or horrendously complicated web sites?

Are you developing public services? Or a system that people might access when they’re in desperate need of help? Plain HTML works. A small bit of simple CSS will make look decent. JavaScript is probably unnecessary – but can be used to progressively enhance stuff. Add alt text to images so people paying per MB can understand what the images are for (and, you know, accessibility).

Go sit in an uncomfortable chair, in an uncomfortable location, and stare at an uncomfortably small screen with an uncomfortably outdated web browser. How easy is it to use the websites you’ve created?

This has me thinking about Camille Fournier’s Make Boring Plans. I read that article .

Good strategy identifies a problem with the current situation, proposes a principled approach to overcome it, and then shows you a coherent roadmap to follow. Strategy is not in the business of razzle-dazzle, it’s in the business of getting to the core of the issues so that the solution becomes simple and obvious. Good strategy provides the clarity that enables boring plans.

Which in turn builds on Dan McKinley’s Choose Boring Technology.

The problem with “best tool for the job” thinking is that it takes a myopic view of the words “best” and “job.” Your job is keeping the company in business, god damn it. And the “best” tool is the one that occupies the “least worst” position for as many of your problems as possible.

It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it. Mature and productive developers understand this.

(and elsewhere) I vented about the language of disruption.

I saw the word “disruptive” and something burst to the front of my thoughts: “That’s some capitalist colonial bullshit.”

When I first started working in the 90s, I helped maintain code written in the decades before. Now, software is a churn and burn, better upgrade your browser, this framework’s deprecated, never take ownership in what you have. It’s bullshit.

Disruption is the language of those that sit outside of a system and care not for the ecosystem in which the receiver of disruption exists.

The thread in all of this? When we use the language of disruption, there’s an implicit disregard for the existing systems and dependencies in which the disrupted operate.

Schools castigate disruptive behavior. But in business or technology, management celebrates and embraces the word. Spot the difference? Disruption, or making the world in your own image, is reserved for the capitalists (e.g. those with the billions behind their name, or who’s unsated maw hungers for billions)

The language of disruption is adversarial, toxic, and predatorial. Adversarial in that it seeks to break apart something. Toxic in that it poisons its meta-neighborhood. And predatorial in that it hopes to feast on the corpse of what it disrupts.

In addition, there is a presumptive arrogance about the ownership of the space we’re disruption.

And assuming it’s “ours to disrupt”, will everyone we’re disrupting have adequate awareness, desire, ability, and means to move and survive along our path of disruption; Assuming it’s a path and not just a scorched-earth-then-stab-a-flag-into-the-ground kind of disruption. In which case, there’s an arrogance and sociopathy of not caring about those impacted.

We, as in humans, develop technology — be it a hammer, ink pen, printing press, spear, scythe, or web browser — to solve problems. We do not experience the same problems, hence we have lots of different technologies.

Those with the most ability, connections, resources, etc. are least vulnerable to disruption. Those with less? For them, the word “disruption” could lead to their abandonment, disenfranchisement, disempowerment, disintegration, or death. Disintegrate, as in not integrated, or loss of cohesion or unity.

When I think about what it would take to learn what has become “modern Web development”, I cringe. It’s a complex stack that continues to metastasize. Driven, by the capitalist, to “Hack the Planet”. No thank you.

To “Hack the Planet” is to champion the ethos that you are detached from the world. That you alone, in your skilled hubris, can shape the world in your image.

The misery of complication that we’ve collectively ensnared ourselves in is promulgated. The modern developer experience demands that your machine process hundreds and perhaps thousands of kilobytes of data and scores of HTTP requests to render a page.

Which means that to use those services, you must kept pace with our disrupting assumptions. So ask yourself, does that sound like you’re the customer? Are you being served?

All of this circles back to using boring technology and writing boring plans. Both of these strategies build shared knowledge and understanding. Boring technology builds from the known tools in your toolkit. Boring plans share your intentions. Their goal is to take the efforts of last year, the knowledge gained, and embark on a change.

These strategies do not preclude “disruption.” Instead they ask you to look around at what you have, write out where you want to go, and how you intend to get there. Ideally, the “you” in those sentences is the plural and not singular.

Then, with these tools and documents, people familiar with the technology and impacted operations can help you navigate, and avoid the known pitfalls that they’ve most certainly encountered and thought about.