4-bit Rules of Computing, Part 5
A software team once changed their version control system's API, removing what they saw as redundant legacy functionality. What they didn't realize was that this particular piece of "technical debt" was actually a load-bearing wall in a customer's factory automation pipeline. The result? A business losing thousands of dollars per hour while the production line stood idle.
In software development, every API endpoint, command-line interface, or file format becomes part of someone's workflow, automation, and daily operations. When Microsoft introduced the Ribbon interface in Office 2007, they broke a promise that millions of users had built their muscle memory around. When a content management system I worked with removed its multimedia MIME-type feature in the name of code cleanup, it left a trail of broken websites and frustrated users in its wake.
We need to carefully balance between necessary changes and breaking changes, which brings me to Rule A: "Fix Mistakes, don't Break Promises". When does a "mistake" become serious enough to justify breaking a "promise"? How do we make necessary changes without leaving our users stranded?
This is the sixth part of my blog series expanding on my 4-bit rules of computing.