Baldur Bjarnason

Over-engineering is under-engineering

– Baldur Bjarnason

There’s a gif going around presenting a debate about whether websites are under-engineered or over-engineered as Daffy and Bugs doing their duck-season/rabbit-season skit.

It’s really only funny if you’re a ‘big project’/‘big organisation’ JS developer. It’s a joke that’s honestly largely indecipherable to those of us outside the big tech corporation trenches doing our smaller things.

Frontend development discussion. pic.twitter.com/Uz7n0Kdnll

— Jake Archibald (@jaffathecake) November 14, 2017

My best guess is that this joke hinges on the fact that most client-side code is severely under-engineered for its actual purpose but also at the same time massively over-engineered.

Both at the same time.

It’s probably obvious to the startup/big-tech-co crowd that most of their work is actually under-engineered: it doesn’t do the job it should be doing.

This is particularly noticeable when it comes to accessibility.

You need to make the form look a certain way and to do that while also keeping the widget accessible requires an enormous amount of, well, engineering.

It’s also an issue for website performance. Most websites are much too slow which means, given that dropping features is untenable from a business perspective, they are by definition under-engineered.

(Again, this is my guess as to what their perspective is. The situations I’ve usually been in tend to be under-staffed and under-resourced. There the perspective is generally more “what’s the absolute least we can do to get the job done”.)

The “humour” then is that they find accusations of over-engineering funny because they know their work is generally comprehensively under-engineered. Hence the rabbit-season/duck-season schtick.

The problem #

These sites are always both under-engineered and over-engineered. Moreover, they are under-engineered because they are over-engineered. That’s the criticism.

When the less-is-more web crowd criticises popular frameworks and libraries for over-engineering, it isn’t a criticism per se of their complexity. You generally don’t become a web developer without accepting complexity as a hard requirement of the modern web. We lament that fact all the time, but it’s there and it’s unavoidable. So, again, the criticism isn’t specifically that these sites’ constructions are complex.

To pick a specific example: the problem with an over-engineered form is that the amount of code required to replace no engineering (i.e. native form controls with basic styling) is enormous and almost always only partially successful (i.e. under-engineered).

They are under-engineered because they are over-engineered. They tried to replace native controls which you’d otherwise get for ‘free’.

This is the basic argument against most forms of website over-engineering: scroll-jacking, manipulating history with pushState, completely customised form controls, etc.

Recreating browser features will almost always be both under- and over-engineered.

Why it won’t be solved #

The web developers working in the (well paid) corporate or proto-corporate (i.e. startups) gulag don’t have a choice. The products they work on need features. And tracking. And analytics. And swishy transitions. And manager-pleasing fancy-pants animation. And they need to follow the corporate visual style. And they don’t know what other teams are doing half the time so they need some form of isolation or compartmentalisation.

The web developers who work for small, massively under-funded organisations or individuals don’t have a choice either. It doesn’t matter whether we’re in-house or freelance, we simply don’t have the resources to follow down Facebook’s path. Re-using the methods, libraries, and tactics common among the startup crowd isn’t an option.

For many of the organisations I’ve worked with the ‘team small enough to be fed by two pizzas’ is the entire goddamn company, including the accountant.

Those companies simply can’t do what the other crowd does and successfully build and maintain products and services. They can use some of the big company methods to ship products but after that things start to fall apart because the maintenance costs of those solutions are simply too high.

So accusing the ‘we have communications problems because the dev team is too big’ crowd of over-engineering will only be met with disdain and mockery. Clearly you are incompetent because you don’t realise that these solutions are almost always under-engineered.

Conversely, being on the other side and facing regular accusations of incompetence and ignorance breeds a fairly healthy disdain for the enterprise/startup side of the scene. (Startups may be small but they always aspire to become ‘enterprises’.)

The only thing we can do #

Maybe it’s time that the web development scene simply accepts that it has fractured into multiple communities, each with different requirements and needs.

Of course, browsers are going to pay undue attention to the enterprise side because they themselves are on the enterprise side. That’s fine as long as they don’t lock the rest of us into re-writing rendering behaviours from scratch using Houdini just to make a basic HTML-rendered web service.

And even though from an outsider’s perspective the enterprise/startup web developer job looks like a huge pain in the arse—mostly dedicated to re-building things the browser already does, just with a ‘this is our brand’ corporate spin—they do also get paid handsomely for their efforts. When they reach my age they’ll all probably own their houses mortgage-free. So, kudos. You do you.

But we don’t all have to walk down the same path in life. And we can’t all make websites the same way.

Edited 12 October 2022.