DRY Is Good. But Know When You Need To Be WET.

This article differs from most others on the issue of WET (‘Write Everything Twice’) in our programs. First, the idea of duplication helping or hurting our systems not only applies to code but other programming artifacts too—like configuration files—which can also exist as duplicates or in a singular form. Second, the current programming orthodoxy very much comes down on the side of DRY (“Don’t Repeat Yourself”). Yet, sometimes it is desirable—even necessary—to duplicate in our systems, as we shall find out.

A WET & DRY Story

A fellow developer recently asked me whether I knew how to link a file between different executable projects in our development environment—and could I show him how to do it. He wanted to reuse a single configuration file for two similar yet distinct services. 

We had a dialogue that went a bit like this.

Me: “Why do you want to link those config files? What are you trying to achieve?”

Him: “Well, I’ve noticed these two services have identical configurations. To avoid duplication, I would like both services to link to the same physical configuration file.”

“OK. I get what you’re trying to achieve. Frequently it seems like a good idea to avoid duplication. Still, let me ask you this: Can you foresee a situation where one of these services may develop in a different direction from the other one?”

“I am not sure what you mean.”

“I could have said that better. I meant, in the future, could one service use a framework, library, or other configurable dependency that the second service won’t?”

“It certainly is a possibility. In fact, I’m currently implementing a more flexible way of notifying users of system events in one of the services, and I am considering a feature flagging tool to gradually switch users from the old notification subsystem to the new one.”

“And this feature flagging tool will need to be configured?”

“It will. And I can see where you’re going with your questions. You believe the new feature flagging configuration settings will cause problems in the other service not using the tool. I can assure you that there won’t be any issues since the system will ignore extra, unused config values. Both services will run fine with a shared config file.”

“I understand that the second service, the one not using feature flagging, will ignore those config values. But don’t you think what you’re planning to do may confuse some developers? Anyone reading through the config file will see the feature flagging setup, yet not find any code in the second service reading and using those config values.”

“Oh, right. I hadn’t thought of that. Yes, that would be confusing. Now that you mention it, if I saw a section in the config file for some behaviour or tool that is entirely unused, I would consider deleting it from the config file to keep things simple. I would probably think that someone had previously removed the feature flagging code, and the config values should also have been deleted, but had been overlooked. Inspecting the git history may prevent this error on my part, but I may not go there since it’s so obvious what happened!” 

And now that the config values are gone, the service using the feature flagging tool would likely crash after the next deployment. Not good.”

“It gets worse; I thought of another reason why you would want separate config files. Another risk with a shared config between both services is that you may run into a situation where you want to use different values for a given config setting. For example, for one service you want to set the WebServerTimeout value to 30 seconds, while for the other service, 60 seconds works better. How can you set different values if it’s the same file? You can’t.”

“Fair point. I’ll keep duplicate configuration files even though it feels wrong on some level. It seems that as programmers we’ve been over-conditioned to seek out and remove duplication wherever we encounter it, even though sometimes it’s important to keep duplicates.”

Conclusion

“In cases like these, I like to be guided by the Single Responsibility Principle, which says that ‘We should keep together those things that change for the same reasons and at the same time and separate those from the things that change for different reasons and at different times.‘ The configurations for your services will likely diverge in the future (even if they are identical right now), so we should keep them in separate config files.”

DRY is good. But know when you need to be WET.