Share utilities, not flow

Sometimes a program you're working on have multiple flows that look very similar.

It could be something like this:

1. Fetch the data.
2. Parse the data.
3. Save the data.

You write each flow separately at first but then notice the repetitiveness. So, remembering "clean" code and the DRY principle you start to combine the flows into one. You feel all smart and smug about it.

But then you run it and it works for one flow and fails for the others. Ah, it seems that data request for Flow 1 requires a bearer token while Flow 2 requires a client ID and a client secret. And Flow 3 doesn't have any authentication at all.

You add some conditions inside of your generic flow.

Then you notice that the JSON parsing fails sometimes. Right, one of the APIs doesn't support JSON and returns to you some weird format called EDN. You add more if statements. Maybe you even get some of the code chunks into separate functions. At this point this is more like sweeping dust under the bed and admiring the clean floor.

You're trapped in this local minimum of keeping one flow to rule them all. Even though it's starting to look like a food experiment left in the fridge for too long.

The best part? Now you get to maintain this code forever or until you quit. Or until you refactor it...

An alternative

I propose a different solution: keep the flows separate but find the parts that are not specific to any one flow.

These are things like network (or IO in general), parsing of common data formats, date and time handling, auth mechanism, etc. Basically, things that don't know and don't care anything about your business logic. I call them utilities. Kinda like electricity, water, gas, internet connection. The electricity doesn't care if you're using it to boil some water for tea or to solder some stuff together.

So you keep your flows separate, each describing a business process for example, but you notice things that are truly generic and then share those. You can now fix a bug in one flow without breaking the others. Each flow's code is easy to read and understand. There are no branches. The data just flows from top to bottom.

There's some duplication but that's fine. That may be a good thing. That may just be familiarity. You know how flows work in your system so, of course, they resemble each other.

Conclusion

DRY is not some law of physics. It's not an absolute. You don't have to eliminate all and every repetition possible. It's a tool to help you spot things that could be utilities: context independent, useful, extremely shareable. Use it with care.