Redundancy is sometimes a good thing. However, redundant code usually isn’t. Creating multiple copies of the same coding logic – whether it’s a C# script, T-SQL procedure, SSIS package, or otherwise – leads to inefficiencies in maintaining the same code base in several locations. This design pattern tends to lead to a technical debt that is extremely expensive to repay.

I’ve been guilty of this. However, after having been burned more than once by this design pattern, I’ve implemented a rule that I work very hard to obey:

Mitchell’s Law: Never write the same code twice.

What does this mean? Very simply, if you’re building business logic that could be duplicated elsewhere, it should be constructed in a modular fashion and made to be as reusable as possible. Almost any code that can be automated can also be made reusable. C# routines can be parameterized and overriden as necessary to eliminate duplicate business logic. T-SQL scripts can be encapsulated in stored procedures or functions in a core library to allow maximum reuse. SSIS packages can be built to accept runtime values via parameters (in catalog deployment mode) or parent package variables (package deployment mode) to get the most out of your business logic.

Like any hard-and-fast rule, some exceptions will come up. The most notable exceptions to this rule are related to security and performance. In multitenant environments that do no permit shared code due to security concerns, it may be necessary to deploy the same code to different locations to comply with regulatory or corporate security rules. Also, when dealing with distributed architecture, using a single code base for certain functions (an example of this would include processing of large amounts of data across geographical distances) may introduce performance problems. However, even in cases such as those, it’s often possible to automate the deployment of your reusable structures to make the most of your coding and testing efforts.

I’m certainly not the first to beat this drum, nor is my implementation of this rule the most elegant. But the message is valuable enough that it bears repeating. Writing code is hard. Writing it twice is twice as hard. Don’t write the same code twice.