One of the ‘heretical’ notions that I have been pressing in a client is something Udi Dahan wrote about some time ago.
In a particular case I experienced recently, we had a production bug based on a change to a stored procedure that wasn’t migrated from UAT to Production.
The particular example is with a stored procedure, but I don’t want to get into the whole “are stored procedures evil” debate here. The problem could have been with a shared data access component, inline SQL, or even with something that had nothing to do with data access. I will say that the answer to whether stored procedures are evil is, definitively, yes, unless they aren’t.
So, we had a fix that we needed to migrate to Production to update that stored procedure. Great. Except the immediate question arose: what other systems besides the system we were fixing used the same stored procedure?
As it happened, the two people who could verify that our Java codebase didn’t use it (as opposed to the C# codebase that needed the fix) were available, and were able to answer within minutes that we were safe. But what if they weren’t available? What if the fix was needed at 3 AM?
Every piece of code should be designed to be used only by one system. This is SRP in its essence.
BTW, this is also why SOA, unless very rigorously defined, is doomed to failure or pain or suffering.
BTW (again), this is why optional parameters in stored procedures or managed code methods are almost always bad. They are optional usually because they are being reused by multiple systems, which means every fricking time you need to change them for one system, you are at risk for breaking other systems.
Reuse of framework code, fine. Reuse of business logic code, bad.