Just recently I had an issue like that. I’ve been using a certain iOS app for tracking my finances for 3 years now. The new update changed the routine: before each transaction was entered with default date of today. Now each new transaction is added with the date of the previous transaction if that one happened during a previous hour. So if I am going through my bills and enter a bill from a week ago and then enter a bill from today I’d have to change the date both times and also check the date all the time.

I wrote a comment about that on developer’s site and got this email in response:

So rather than improving the app to make it easier and less work to add transactions, you want me to optimise for people who don’t pay attention to what they are doing? Surely that makes no sense whatsoever!

Chris Wellons wrote:

If you have 10,000 users and you make a minor breaking change that requires on average 15 minutes for each user to re-learn the user interface, or whatever it takes to deal with the change, that’s a cost of over 100 man-days for that modification.

Ouch, where I work we’re expected to put in an eight hour day on average. Your place expects you to work every waking moment? ;)

For reference — and this isn’t to be pedantic, but to show how you’re actually underselling your point — a “man-day” is usually defined as a work day, not a 24-hour day. Assuming that mythical eight-hour day, your example actually costs over a man-year. Ouch.@ Jason *StDoodle* Wood:

This mirrors some information I gleaned about Microsoft’s plans for Azure – the online version of SQL Server. They are planning to apply regualr patches and fixes directly to the Live cloud environment. So, anyone with an application that uses an Azure database could find it’s legs kicked from under it by a patch change. They won’t have a test environment, it’s “bang” and the change is made. Of course none of this will concern managers who will long gone before the chicken comes home to roost!

I like your definition for “non-trivial number of users.” That really does sound like a perfect metric. If you have 10,000 users and you make a minor breaking change that requires on average 15 minutes for each user to re-learn the user interface, or whatever it takes to deal with the change, that’s a cost of over 100 man-days for that modification. It adds up!

Your problem description can be generalized to all interfaces, human or otherwise. That’s fundamentally why we have dotted version numbers. If version numbers were merely about features and bugs, all we would need is a single integer: “Foobar Pro only has feature X in versions 5 and above.” (I guess this is the trend that browsers follow now.) The major.minor.patch convention primarily exists to describe interface compatibility between versions. Patch increments are backwards-compatible bug fixes. Minor increments are backwards-compatible changes that might introduce new features. Major increments are breaking changes. This is mostly about APIs, though. I don’t think user interfaces are often considered when versioning, but maybe they should be.

We’ve run into this problem a lot recently in the Emacs community with the relatively new package.el. There’s MELPA providing bleeding-edge packages, and these packages sometimes change their interfaces without warning. It’s annoying for me because sometimes it means I have to stop what I’m doing to update my own usage of the package, such as changing which of its functions I call or how I call them. To start working around this, a stable version of MELPA was introduced for hosting stable versions of packages — a repository where changes to interfaces are more conservative. This is sort of like Debian, with its stable, testing, and unstable repositories.

This reminds me of a project people I’ve worked with on my university were working on:
Ali Baba is a java applet from 2005 that displays a graph of genes, proteins, diseases and medications that are mentioned together in medical papers and is fairly bad at it. It was made for medical research (and people needed to show off what an amazing database of text-mined medical papers we have, it really is quite cool). Now you ask yourself why my university still supports a java applet. It is not because there is some old prof sitting and thinking this is the latest shit, contrary this specific work group consists of relative young and very talented people. The reason it’s still up is that every time they take it down they get a few dozens of emails complaining about the discontinuation of the authors favourite mind mapping tool.