Text I wrote from an email nearly two years ago, after a corporate re-organization:
Here is a common scenario at a megacorp, a glimpse into “real programming”. Group A (imagine they’re the point-of-view character in this story) makes a software component, and it is widely well-received. Group B hears about it and wants to use it months later, and A excitedly points them to the docs. A has moved on to another project as no longer using this software component. However, when Group B tries to use it, it breaks because it actually depended on behaviour in another software component that Group C have changed in the meantime. Now it’s a tie between 3 groups on whose job it is to fix it. A suggests that B coordinates with C. C says that the usage by A was out of the intended support scope, or they could do the fix and offer to put it somewhere indeterminate on their roadmap, since it isn’t their job to directly support B. B is now annoyed because they felt A made a promise and it wasn’t fulfilled, when in reality A offered a potential solution to a problem B might have had to make themselves if A hadn’t happened to already have done this work.
What most often happens in practice is that B, in a hurry, “fixes” the software component, which is some horrible hodge podge that hardcodes the software component so it only really works for B. In this scenario, B is the most “end user” of these groups and less thinking about long-term software maintenance, and even in kind of a hurry. Sometimes this entire thing happens without A or C being aware of this, only finding out months later. Sometimes A finds out only when a new project requires them to use the software component again, so they return to find it broken and less maintainable. When A complains to B about this, B tells A that they should have helped them out when they asked.
A, B, and C are each at least 10 people, and in many cases aren’t even aware of each other’s existence.
Now before you say “A should have written a test”, lots of new behaviour in complex scenarios is hard to write tests for, and sometimes tests in our space are non-deterministic. So we can’t write tests for everything. Also, I’ve seen professionals write tests that boil down to “fail if the source code changes at all” and then pat themselves on the back.