The Cost of 'Verschlimmbesserung': Why Software Updates Often Make Products Worse
Misaligned incentives and illogical metrics drive counterproductive software changes in the SaaS era.
Modern software users are increasingly familiar with the frustration of an update that breaks a reliable workflow in the name of progress. This phenomenon is captured by the German term 'Verschlimmbesserung,' which describes an attempted improvement that ultimately makes a product worse.
In a recent analysis, Geeky Schmidt argues that this trend is not merely a series of technical errors but a systemic issue within product teams. According to Schmidt, 'Verschlimmbesserung' in software is frequently driven by teams optimizing for illogical metrics, such as rewarding the act of shipping new code over the actual improvement of the user experience. This creates a cycle where updates are released to satisfy internal KPIs rather than to solve genuine user problems.
The Logic of Illogical Behavior
To explain why engineering teams produce these counterproductive updates, Schmidt references the theories of Eliyahu Goldratt regarding measurement and behavior. Goldratt’s management axiom posits: "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."
When product success is measured by the frequency of deployments or the volume of new features, engineers are incentivized to change things regardless of whether those changes add value. This contrasts sharply with the era of stable, enduring software. Schmidt points to the long-term utility of legacy products like Office 2003 as a counterpoint to the modern SaaS model of 'constant reinvention,' where stability is often sacrificed for the sake of perceived activity.
Why Stability is a Feature
The consequence of this shift is a systemic failure in how product success is incentivized. In the current SaaS landscape, frequent updates often disrupt established user workflows without providing a tangible benefit, leading to a degradation of trust between the developer and the end user.
Schmidt suggests a fundamental shift in engineering philosophy: stability must be viewed as a feature in its own right. By treating the decision not to ship as a critical engineering discipline, teams can avoid the trap of 'Verschlimmbesserung' and prioritize the long-term reliability of the tool over the short-term satisfaction of a shipping metric.
The Path Forward
As the industry grapples with the friction of the continuous delivery model, the focus may shift toward more nuanced success metrics. The challenge remains for product leadership to align incentives with actual user utility rather than output volume. Until stability is valued as highly as innovation, users can expect more updates that attempt to fix what isn't broken, only to make it worse.