Software: how complex should it be?

(20 … 20 … 3 … Might as well start to get used to typing in a new year number right away. Christmas and New year's have passed in somewhat more of a blur than usual, and if there is such a thing as a gray, uneventful January then I would not mind at all.)

I stumbled into a short discussion on Mastodon about image handling for static websites, and eventually realized that I was most likely in the wrong mindset and position to have an opinion even remotely useful to anyone involved. The discussion was actually about advantages of and possible solutions for doing light CMS:ing for images alongside your standard static site generator. And my unhelpful and not at all interacting opinion was that this all sounded like a lot of complexity for something I am not interested in doing.

There are various clever-sounding ways I could have dressed that up, but it really boils down to me not being interested in solving the problem. My mind went off into various interesting thoughts about needless complexity and solving problems by using less code, none of which really had anything to do with what everyone else was talking about.

Good thing I did not try to write more, that would just have got in the way of everyone.

This page, however, is a safe, non-intruding space, so I would like to pull a bit more on one of my thought threads:

If, in the process of writing online, you find yourself thinking about things such as build pipelines, CMS stuff, and image metadata, what has happened? Are there options other than these two:

  1. You have found an enjoyable rabbit hole to go down
  2. We have once again built much too complex hammers for the very simple drilling needs of most people

Number 1 is great! Go forth and have fun!

But number 2 … Why do we keep building these twisting mazes of passages, all alike? Should a static site generator really need to do anything more complicated than converting Markdown (or equivalent) to HTML and do some string replacement? Should there, really, be the need for anything even at risk of being labeled a pipeline?

Oh, and should the result be anything more complex than a folder which you could trivially (S)FTP somewhere to publish it? Remember, we are talking about blogging, not supporting enterprise-grade infrastructure.

(Although I suspect that some enterprise-grade infrastructure could also benefit from being similarly simple, and that a portion of the rest actually runs in whole or part by simple things like five-line bash scripts and FTP operations.)

One answer is of course that building ever more complex and competent stuff is fun. Another is that as software gains more users and use cases, changes will often be requested which are a poor fit to the original shape of the software. Something gets bolted on to one side, something else to the other, a few abstractions are created to make things more general, and all of a sudden we are back to pipelines and package management.

I have no good answers (to anything, ever, really), but I come back to that gut feeling I got reading the original thread: For the things we talk about doing, nothing should need to be this complex.

Is more highly customized software an answer? Is it possible that every person's static site generation needs could boil down to, say, 300 clear lines of Python? If everyone had their own 300 lines, would we end up with more or fewer lines of code to understand and maintain (compared to now, when people download and install general static site generators (and their dependencies (and their dependencies dependencies (…)))), and would those lines be easier or harder to read and debug than what we have now?

I sometimes think about adding new features to Bakery, but with an audience of one it is remarkably easy to not fall into the trap of needless generalization or feature addition. It may be too bold to say that it has actually saved me time over the years compared to if I had used some other solution, but it is not out of the realm of possibility. I am growing slightly bored with the look of my site, but when the day comes that I get around to that, I have a maximum of three different files to dig through to implement my changes. There will be no outdated packages, no OS incompatibilities, and no breaking changes to the layout engine or deployment pipeline.

Old man yelling unfinished sentences at clouds out.