Code Reuse is Bad

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.

<digression>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. </digression>

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.

posted on Friday, March 18, 2011 10:12 PM Print
# re: Code Reuse is Bad
3/19/2011 4:26 AM
I didn't get the point why SOA is bad, could you please comment on that? I mean a lot of enterprise systems use it with distributed bussines model implemented through CQRS/DDDD.

# re: Code Reuse is Bad
Eber I
3/19/2011 8:59 AM
Just sounds like business logic in stored procedures is bad
# re: Code Reuse is Bad
3/19/2011 8:52 PM

SOA, at least as far as I understand it, has always been based on the idea of reusing services, which ultimately means reusing methods on those services.

A problem with SOA has always been that as new business requirements are discovered/defined, you have to update the contract of that service, and so versioning has always been an issue.

When the contract of a service needs to be updated, if you have multiple clients of that service, you now need to know whether that update will break every single client consumer.

If you design your service so that any method is only used by one client, you can safely push updates.

The 'downside' is that you end up with a proliferation of methods. What I'm arguing is that this 'downside' isn't really a downside when you consider the alternatives.

Post Comment

Title *
Name *
Comment *  
Please add 7 and 5 and type the answer here: