A thesis: most websites are implicitly designed with a short lifetime

January 30, 2022

Over on Twitter I said something:

Thesis: most websites and their technical design are designed for the short term and implicitly for short lifetimes. Five years? Maybe. Ten years? Most people aren't thinking about that sort of lifetime. Fifteen or twenty years? Forget it, it'll be plowed under by then.

An organization and its website may live for a long time (and many people hope for that). The visual design and interaction of the website is likely to change and turn over more frequently, partly because the entire web is full of design trends that come and go; keeping your website's look 'up to date' requires changes. On top of that, the capabilities and constraints of the devices that your website is viewed on keep changing. My strong impression is that the technical decisions and design are considered to be even more ephemeral than the visual design, with people accepting that there will be significant churn in that area over time.

(One reason for technical churn is that many organizations expect to grow and scale up, and sometimes they will have to scale down certain lines of business.)

I don't think people building websites explicitly think about the expected lifetime and plan for whatever specific lifetime they expect (at least, not usually). But I do think it influences what technologies they consider and choose, and in particular I think people are influenced by a general feeling that no matter what they do, it's probably not lasting for all that long. Or, to put things another way, they won't be stuck with what they've built for all that long, left to operate and maintain it no matter what. Something will change enough to force changes regardless of what they do.

(This is in one sense an analog to the programming argument of YAGNI, which very roughly that you can't predict the future well enough to engineer for it beyond general principles, so you should build what works for you today.)

I believe that if you asked people building websites to explicitly consider that their work would have a relatively long lifetime, say ten years, that you would get somewhat different technical designs. Or at least I would like to hope that you would, and that people would consider issues like how much churn there had been in various technology choices over the past ten years and how much there might be in the next ten. I think you would get rather different designs, and those designs would be easier to keep running for ten years.

Also, a lot of the time this would be overkill, because people are right. A lot of websites do not get to live more or less as-is for ten years, or even five, because external requirements change too much. The organization changes, the needs change, the scale that the website is working on changes, and so on.

(This thesis is partly sparked by reading this article and having reactions to it.)

Comments on this page:

I can see how they would appear analogous but IMO the similarity between YAGNI and YAGBSWI (you aren’t gonna be stuck with it) is only superficial. The former says you shouldn’t try to solve for imagined future requirements, whereas the latter is about your selection process for solutions to your known requirements, for which it says you should optimise for initial velocity above all else. The observed effect should be YAGNI pushing you toward less complexity where YAGBSWI gives you license for more of it.

Sometimes a website unexpectedly ends up being alive, unchanged, for a long time. I've been pushing for work to replace/update a Drupal 7 (EOL: November 2022) site and its "wow, PNGs with alpha channel work now!" era theme. I may eventually have to port the theme. In any event, we still have ongoing maintenance of it: the core CMS and module updates, TLS certificates, and that time we had to split it off to its own PHP version because D7 rarely supported new versions by the time everything else was ready to move.

But if you had asked me back in 2013 how long I expected to be on D7, with D8 already coming over the horizon, I would never have guessed more than five years.

Regarding the static/dynamic split, it used to be a huge deal to have an application server; it would consume far more of your extremely limited memory, and drop the request rate by two orders of magnitude. A static site was qualitatively different because it didn't require any process switches, once the HTTP server had the request.

My static website is built to last, without any major changes to article URLs. Ironically, I hate the WWW, and want it to be destroyed so that I can eliminate my website. People who actually like the WWW tend to be swept up in whatever the latest nonsense is.

Written on 30 January 2022.
« The reason Unix has the argv[0] issue (and API)
Git 2.34 has changed how you configure fast-forward only pulls and rebasing »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jan 30 21:41:29 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.