2023-10-28
Thinking about the sensible limits of customization of things
Recently, for reasons beyond the scope of this entry, I've been mostly handling my email in GNU Emacs, with MH-E. GNU Emacs is famously flexible and customizable, mostly through the somewhat challenging method of 'merely' writing the relevant (Emacs) Lisp code to do what you want. I'm capable of writing Emacs Lisp, so armed with a hammer and using a new mail client, I have been finding plenty of things to use that hammer on (sometimes with hackery and Emacs crimes). At this point, I've accumulated something like 1500 lines worth of customization (although that includes a lot of comments), and I can think of more things that I might do.
(Some of this customization is because MH-E doesn't quite do what I want it to do, sometimes it's because I want a more convenient way to do what it already can do inconveniently, and sometimes it's because I'm trying to recreate features I'm used to in exmh.)
Several years ago I read Tobias Bernard's Doing Things That Scale. To summarize the article badly, Tobias Bernard talked about how they had moved away from customizing things (and then having to maintain the customizations) in favour of doing generally useful changes to upstreams. This argument gave me tangled feelings that I've yet to sort out enough to write an entry here about, but part of it is certainly on point. Every customization I make to my Emacs and MH-E setup is effort to write, effort to remember, and effort to maintain. Do I actually need an ultra-hyper-customized MH-E environment? Am I going to even use all of these hacks I've done? Both clothes and mail clients can be comfortable and useful without being form fitting.
Of course, this is a personal version of something that I run into all of the time professionally, as a system administrator. There's a lot of custom scripts, custom Prometheus metrics exporters, custom web things, custom mail system features, and so on that we could write and put into production, but all of them have both a cost and a benefit, and sometimes the costs are not worth the benefits. Just because we can do something doesn't mean that we should. At the same time, sometimes we should, even if the customization is large and thus the costs are significant.
(For example, we have a bespoke custom ZFS spares system, which was a chunk of work to write and tune, but on the other hand has been rock solid and lets us basically not worry about disk problems. And our very custom simple mailing list system is quite appreciated by our users, although the Exim configuration involved is surprisingly complex.)
I don't have any particular answers, either for my sysadmin work or for my GNU Emacs hacking. But I do want to think about the question at least a bit, even (especially) for my own GNU Emacs coding. Just because something is an interesting Emacs Lisp problem doesn't mean that I should solve it, especially if I'm currently immersed in solving Emacs Lisp problems. And just because I can tweak and customize something doesn't mean that I should.
(Solving Emacs Lisp problems is a little bit addicting for me, much like any programming. Sometimes I have to pull myself away from the urge to do a bit more and then a bit more and so on. Hopefully this urge will pass.)