The Linux 2.5, Ruby 1.9 and Python 3 release management anti-pattern
<i>In retrospect, and looking at what those projects have been doing in recent years, it is probably a better idea to break early, break often, and fix a constant stream of breakages, on a regular basis, even if that means temporarily exposing breakage to users, and spending more time seeking strategies to limit the damage caused by introducing breakage.</i><p>It amazes me how the author managed to conclude completely the opposite from what he described. Make the users experience the breakage. On purpose. To me as an engineer, that&#x27;s utterly unacceptable.<p>Empathy is still a core engineering value<p><a href="https:&#x2F;&#x2F;www.listbox.com&#x2F;member&#x2F;archive&#x2F;182179&#x2F;2013&#x2F;05&#x2F;sort&#x2F;time_rev&#x2F;page&#x2F;1&#x2F;entry&#x2F;1:75&#x2F;20130508172342:8CF96552-B825-11E2-98EE-8CBB5940B2DC&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.listbox.com&#x2F;member&#x2F;archive&#x2F;182179&#x2F;2013&#x2F;05&#x2F;sort&#x2F;t...</a><p>the solution isn&#x27;t to expose breakage to users in order to make the developers&#x27; lives easier; we are developers precisely because we are to tackle the difficult problems, so that users could get work done.<p>As engineers, we convert the science and the theory into working products and tackle difficult problems so that useful work could get done. If we are disrupting the users so that our work and lives would be easier, we don&#x27;t respect our users. We should never make our work easier for us at the expense of our users.<p>The solution is to design for backwards compatibility from the onset; version interfaces if you can&#x27;t predict for the future, but always remain backward compatible. This way, new consumers of the interfaces benefit from the new features transparently, and existing consumers continue to function without disruption. Plan ahead; don&#x27;t just code: planning is 50% (or more) of the work.