Blog post: bad software updates have a name, Verschlimmbesserung

A blog post revives the German word Verschlimmbesserung, an attempted improvement that only makes things worse, to describe a familiar pattern: a SaaS product ships a "better experience" that moves a button, renames a menu, and breaks a workflow people relied on daily, solving a problem nobody had. The author traces the cause to measurement, quoting Eliyahu Goldratt: "Tell me how you measure me, and I will tell you how I will behave. If you measure me in an illogical way, do not complain about illogical behaviour." The argument is that when point releases become more important than the product itself, that incentivises Verschlimmbesserung, and that engineering teams are not failing when this happens, they are optimising for the metrics they were given. If the metric rewards churn, the author writes, you get churn; if it rewards shipping, you get shipping, whether or not it improves anything. The post questions whether newer is always better, pointing to Office 2003 as still useful precisely because nobody forced it to keep reinventing itself, and concludes that stability is a feature and that knowing when not to ship is an engineering discipline. No specific company, product, or update is named as an example, and no figures are given for how often the pattern occurs or what it costs; the piece addresses an unspecified "you" rather than naming who sets the metrics in question.

Key facts

  • The post names the pattern with the German word Verschlimmbesserung: an attempted improvement that makes things worse.
  • It quotes Eliyahu Goldratt: "Tell me how you measure me, and I will tell you how I will behave. If you measure me in an illogical way, do not complain about illogical behaviour."
  • Its core claim: engineering teams are not failing when this happens, they are optimising for the metrics they were given.
  • It cites Office 2003 as an example of software that stayed useful because it was not forced to keep reinventing itself.
  • No specific company, product, update, or figures are cited; the examples in the post are generic, not documented cases.

Why it matters

The post gives a name to a complaint most software users already have, an update that moved a button, renamed a menu, or broke a workflow while solving a problem nobody had, and locates the cause in incentives rather than incompetence. Its central move is reframing: a team that keeps shipping disruptive changes is not failing, it is doing exactly what its metrics reward. That reframing is why it resonated widely (121 points, 74 comments on Hacker News) even though it names no company or product.

Who it affects

The argument is aimed at whoever sets the metrics for a product team, described in the post only as an unspecified 'you', which it frames as implicitly meaning product or engineering leadership, plus anyone who has been on the receiving end of a SaaS update that broke a familiar workflow.

How to use it

The post is an argument, not a tool or checklist. Its practical implication is that a team wanting to avoid Verschlimmbesserung should examine what its release metrics actually reward, shipping frequency and churn versus whether an update helps users, since the post argues teams optimise for whatever they are measured on.

How solid is it

The piece is an opinion essay, not a study. It supports its claim with one named quote (Eliyahu Goldratt) and one named example of stable software (Office 2003), but cites no data on how often the pattern occurs, its cost, or which companies or metrics it is describing. The reasoning is a general argument from incentives rather than a documented case.

Risks and caveats

No specific company, product, or update is named, so the central claim is illustrated by a generic, relatable scenario rather than a verified instance. No figures back the frequency or cost of the pattern, and the post does not identify who sets the metrics it criticises, leaving the argument persuasive but unfalsifiable as written.

“Tell me how you measure me, and I will tell you how I will behave. If you measure me in an illogical way, do not complain about illogical behaviour.”

— Eliyahu Goldratt, quoted in the post