YAGNI, Scalability and having fun #

Prior reading #

Firstly this expands upon my earlier thoughts last week regarding YAGNI and Scalability^[1]. This was also inspired by Fernando Boretti's blog post "You Can Choose Tools That Make You Happy"^[2]. See these blog posts below in the links section. It's an excellent article that you should also go read!

The importance of fun #

Firstly, ignoring both YAGNI and Scalability I wanted to take a moment to point out the importance of fun and joy in your tools. It is like a writer opting to write their drafts with pen and ink, or opting to use a typewriter. I find that joy with my tools leads me to do more work and faster, simply because when I enjoy something, time loses its grip and I can enter flow state far more easily.

However when my tools irritate me, and I scrape up against their sharp rusted corners... it's friction and frustration. The moment is lost, the flow state is disrupted and the work flows like mud once more.

Just for fun alone... fun tools should be considered.

YAGNI and Scalability #

As previously discussed in last week's blog post, plenty of work will never need Google-scale engineering or optimisations. I won't belabour this point, and take it for granted here... but considering this, this grants you, the developer, the leeway to choose the tools that make the development process more enjoyable.

An excellent example of this can be seen in Minecraft. Java was a terrible decision for a game to be programmed in for a handful of reasons mainly around the Garbage Collector, but Minecraft exists and it built upon Notch's knowledge of Java from multiple Game Jams before it. As a result it got made faster and the iteration speed and joy of development is apparent(especially when you look at some Notch's early posts on developing the game).

Another advantage to this approach is both allowing you to diversify and concentrate your knowledge. Diversifying when there's a new fun tool you want to use, and concentrating when fun is using what you can develop with fast and well(of course this is also dangerous if you become a monkey succumbing to Shiny Object Syndrome and trying every new thing. It's also dangerous if you use too many tools, as you'll start to spread yourself a bit thin).

The Danger of this approach #

There is a danger to this kind of mindset though. The first is that if you're choosing fun tools that have poor support by others... you'll be fully responsible for it. I feel this myself using werc for my website, as CGI-based sites are already something that is uncommon on the modern web, and it is doubled by using the rc shell which also is very uncommon(A Plan9 shell) and using werc which has a very small number of people using it that I'm aware of(probably less than 100?). As a result, if I ever used this stack in any project where I hired people, I'd be solely responsible for training them on it... There is some merit to the path well-trodden.

The other danger, goes back to my IndieWeb Carnival theme post^[3] around "Good Enough" being a siren song for dropping standards of quality.

The other danger is that you could also spread yourself thin, split between multiple tools. You could end up like a Linux Distro-hopper, and never get anything done.

Like in all things, a balance should be met... and you have to make that choice, and often you won't know the best road unless you go down both and measure both and enjoy both(which is a luxury afforded to very few, and repeated often as a platitude). Given how much employee churn and burnout there is in software development, and given the fact that most projects will not have google-tier scalability requirements...

Perhaps you should choose something that gives you joy on your next project?

Minor Notes #

Where I say fun or joy, you can also substitute it for satisfaction or just plain having less friction. I wouldn't really consider Linux to be fun or joyful nowadays, having used it for quite a while... it just has less friction and is less abrasive than the alternatives.

Footnotes #

Published on 2025/05/26