For a rewrite or a replacement of existing software, very often you will find that the minimum you must achieve is something that works at least as good as the previous system in every respect, for all your users all of the time. Perfection is table stakes.

This is quite annoying if you happen to have the job of doing the rewrite, and not understanding this is a source of agro.

Here are a couple of examples from the Open Source world:

• Pulseaudio is a “sound server” for Linux. A sound server is the part of your audio system that manages the fact that multiple applications might all want to be playing at once, and the multiple sound input/output devices you might be using.

  Before Pulseaudio there was a different system, and the first time my system was “upgraded” to Pulseaudio, it had poor sound quality for some apps. I’m not an audiophile, but the cracks and pops and hissing were very obvious to me.

  Now, compared to the previous system, Pulseaudio also came with a bunch of new features, like the ability to have a per-application volume control, and do sound over Bluetooth more easily. But I didn’t care about those features I had been given (I didn’t need them), while I certainly cared about music sounding bad. Perfect sound quality, all the time, is the minimum you have to achieve as a sound server.

  I also found that if I uninstalled Pulseaudio, then I got back to the previous state where I had ALSA which just worked, and everything sounded fine. So I was pretty annoyed at this “upgrade”.

  That was some years ago, and these days Pulseaudio has now apparently been replaced by Pipewire in my current Linux system. This happened without me knowing it, and in fact this is one of the highest compliments you can give to a rewrite or replacement system: the users didn’t notice.

• More ambitiously in Linux world, there is Wayland, a project started in 2008 which is attempting to replace the X Window System as the protocol for how to do a windowing system, graphics output and keyboard/mouse input (so, almost everything you consciously interact with on a computer). Unsurprisingly, this is a lot of work, and there are still lots of things that don’t work for some people, and lots of problems that people didn’t have before.

  Such reports are going to be pretty frustrating for the creators of the new system, whose only reward for decades of work, usually done for free, is a long list of complaints.

  But for anyone who is forced to switch, if they find any regression in anything at any level, they are going to say “this sucks”. And fair enough - why should they care about all the work you did when the end result for them is worse? Why should they care about all the new features, which they don’t yet need (or don’t know they need), when some of the existing features they definitely do need are now broken?

So, what is the lesson? Don’t bother?

Rather, I think it is this: go ahead and do the rewrite, just buckle up, and set your expectations properly.

Until it has reached 100% of what it is supposed to replace, you will mostly get complaints. Don’t expect to be thanked for all your work, whether it is paid and commercial or free Open Source development. Nobody cares about the fantastic architectural improvements (which mainly help you, not them), nor about the new features they aren’t using yet. Don’t complain about the complainers and the naysayers, or ask them to shut up, or pretend that their problems don’t exist - why shouldn’t they complain, when you made their life worse?

(Do the complainers actually have a right to complain? As a side note, when talking about this with my wife, her view was that they really don’t, and maybe they should think about paying for this free software before complaining. This is coming from the perspective of “a wife of an Open Source project maintainer who spends a lot of hours on projects for which he is not thanked (or paid)”. But however much truth there is in that perspective, people will complain, and I don’t think it is sensible to assume otherwise).

I’m writing this down partly for myself, as I start a project rewriting a working piece of software for a client. This rewrite will include a large interface overhaul as well as a lot of internal architecture changes, and I’m hoping that the interface changes will be welcome.

However, I have to prepare for the fact that initial reactions will likely be negative, or not nearly as positive as we might expect, because just by changing anything I’ve already made someone’s life worse: having to relearn how to do something they used to know is not most people’s idea of fun. To make up for that, if I want them to be positively enthusiastic, not only do I have to cater for every need and fulfil every previous expectation, the improvements have also got to be both large and obvious — it’s got to be an absolute slam dunk, from the very first time they try it.

We’ve got a tiny number of current users for this application, so compared to the other projects I mentioned, the stakes are much lower and we should be able to accommodate everyone’s needs. But getting my expectations right, having empathy with the user, is essential.