Fabian Holzer

On unintended consequences

Consider the following scenario: an engineer demonstrates a problem and sketches a simplifying solution. The problem as such is accepted, but the proposed solution is rejected. The result is new work in the backlog that overhauls the existing functionality with something more complex. The new solution is slightly (but not essentially) more powerful. It maybe be better from a business/product management/sales/design perspective (what ever the metric of choice is).

An attempt of simplification, which results in bloat, is a perverse outcome from an engineering perspective. The engineering lense is of course not the only one, but a system that is to be maintained in the long run, surely shouldn't completely disregard it. For what could be a second-order effect of such a decision?

In the worst case: the creation of an incentive be silent. A motivation to stop contributing suggestions, and sweep issues under the mat. Such a potential breakdown of communication and feedback is a real threat for the quality and structure of any system. If a canary in the coalmine stops singing, miners know that it is time to get out.

Those who are tasked with creating systems would do good to be reflective of this, and if necessary take measures to counteract it.