Iterative Tinkering depends on API stability

["Dr. Arne Babenhauserheide" <arne_bab@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]

Hi,


Sacha Chua writes how she tinkers incrementally, finding time between
tasks, asking “What's the smallest step I can take? What can I fit in
15-30 minutes?” — Choosing what to hack on:
https://sachachua.com/blog/2024/01/choosing-what-to-hack-on/

This approach improves the work environment step by step to become
better than any other. In a similar way, I now ended up using exwm, and
while not perfect, it just works better for me than all other systems.

But since this depends on doing small steps and moving forwards in
little steps, there’s no time for large-scale maintenance. You define
what’s the right step, and then you take it.

If something breaks, that takes up at least a full improvement slot.
Often just searching for a solution takes longer than you have.


So this approach — which can lead to the best personal work environment
possible — depends critically on API stability. Even a deprecation that
affects multiple of your modifications can put a stop on tinkering for a
long time, because fixing something that broke due to changes from
someone else is a very different kind of working than letting your
curiosity lead to even out a rough edge in your workflows.


Someone would surely come in and quote xkcd 1172: https://xkcd.com/1172/
I consider that a harmful strip — it has a point, but it got weaponized
to brush away concerns about stability and muddies up the understanding
that those with the most complex or most advanced setup are the ones
most likely hit by API breakages.

If you see 1172, remember that Lilypond had almost ended up ditching
Guile because of breakage that hit them with the 2.0 release. The one
Guile-using tool that is absolutely dominant in its domain (the most
beautiful music scribe) had almost stopped using Guile.

For Emacs, the impact is even bigger, because far more people tinker to
optimize their setup.


And recently I’ve seen more breakage in Emacs.

For example my address completion in mu4e broke a week ago. I don’t have
time or energy to fix it. And mu4e started to send emails to myself if I
answer my own message in a thread with someone else, because the R
shortcut no longer sends wide replies (W shortcut). And there’s a risk
that it will stay broken: storing each address I send emails to in mu4e
automatically has been broken for years. It took me months before I got
to fix my org-mode setup when it suddenly started indenting lines while
typing. That actually affected me live while giving parts of a lecture
interactively.


So I want to plead to remember the risk of volatile software¹, volatile
infrastructure², and soft trauma³, when taking decisions about backwards
compatibility.
Breaking backwards compatibility has much wider-ranging implications
than it seems while working on code, and it hits the most most
advanced specialist tooling and the most enthusiastic tinkerers the
worst.


¹ Volatile Software — do not be the tool which breaks itself or other
  tools on update.
  https://stevelosh.com/blog/2012/04/volatile-software/

² Volatile Infrastructure is worse than volatile applications.
  https://www.draketo.de/software/volatile-infrastructure


³ Software developers should avoid traumatic changes — two kinds of
  trauma: everything needs work to get working again or to get idiomatic
  again.
  https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html


Best wishes,
Arne

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]