In The Code Reuse Paradox , I illustrated some problems with writing reusable code: developers must know which code to generalize, how far to generalize it, and how to tell when they’re done. The challenges writing reusable code are nothing new, of course — they led to the rise of loosely-coupled Services.
In order to build a reusable Service, so the story goes, you must make it agnostic. By agnostic we mean that you don’t know how the Service will be used when you create it. Instead, you simply put “generic” logic in the Service, so that future consumers can leverage it in ways you may have never dreamed of.
But by specifying generic logic, we’re back to the challenges from the last blog post. How do we know whether logic is generic, if we don’t know how people might want to use the Service in the future? The answer is that in practice, we always have some expectation of future uses of a Service, even if those future requirements are only implied or hinted at.
For example, let’s say we’re building a credit check Service. Today’s requirement is to automate a mortgage approval process, so we’re implementing an orchestration of Services, one of which is our credit checker. But we say to ourselves: other processes will need to check credit as well, so let’s make sure our credit check logic is generic, so that the Service will be agnostic. Input a Social Security Number and output a three-digit FICO credit score. Sounds generic, right? What could be simpler or more reusable?
A few months later, a different development team is looking to automate an auto loan approval process, and they dutifully query the Service repository to determine whether any existing Services will help with their task. Sure enough, up pops your credit check Service. They download its metadata and plug your Service into their orchestration. Simple as pie, right?
Not so fast. Didn’t you know that FICO has different credit scores? The ones for mortgage applications are actually different from the scores they provide for people buying cars. Oops! Now the car loan team is in a bind. If they reuse your Service they’ll get the wrong score, but if they build their own, they’re violating the policy to reuse Services when available.
The answer to this problem is relatively straightforward, especially if you’re familiar with Agile approaches. Never expect requirements to be fixed — even for agnostic Services. Instead, take an iterative approach that allows for refactoring of existing Service logic. But don’t refactor until there’s a reason to. Balance the values of efficient code with reusable code, but when in doubt, lean more toward efficiency. You (or someone else) can always tweak your code later to meet a future requirement.
Does that mean your credit check Service isn’t reusable? Absolutely not. Instead, we’re casting reusability into the Agile context, which allows for refactoring to address changing requirements. As we say on the Web, digital ink never dries. The same goes for your code.
