Software Wind Window
One day I found myself in a very counter-intuitive situation reviewing a pull request, I was asking a colleague to create some code duplication, and duplication is a very bad word for developers. He was sensibly making the case against duplication, bringing code reuse, single source of truth, clean code, etc into the discussion. We developers spend our entire lives being hammered with those concepts, how on earth was I advocating for duplication? So the question is: Is duplication always a bad thing?
Before we dive into this discussion allow me to quickly present some kitesurfing basics, in the the end it will all make sense, I promise. To be able to kitesurf you must understand the wind window and how to harvest its power. In a nutshell, you need to fly the kite and make it do figures of eight in the sky, by doing it the kite will pass through different power zones and pull you forward. The kite can’t stop moving, if you leave it only in one place it loses power and crashes in the water.

So what does kitesurfing have to do with software?
Technology is by now accepted to be an inseparable, integral part of most businesses, knowing how work with it is a matter of life and death for many companies. To really milk the kitesurfing analogy, let’s assume that controlling the kite is the equivalent to maintaining the codebase, the surfer is the tech team and the whole system (wind, water, surfer, board, kite) is the business. And last but not least gravity, the force that pulls the kite down, is basically software entropy.
Entropy is a borrowed concept from thermodynamics, it’s a property which guarantees that things have the tendency of disorganising themselves. Fighting entropy (keeping things organised) is an energy intensive task, but in the end entropy always wins. Against entropy there can be only temporary victories. The same goes for software entropy, it always wins.
The software wind window explained
So I was puzzled by this aparent contradiction of me advocating for duplication and kept thinking about it, then a graph started to appear in my head. Code reuse and duplication are opposite forces, they null themselves like matter and anti-matter. Same thing happens with ambiguity and contexts, the more context you give to something the more specialised and less ambiguous it will be. These two concepts can be the X and Y axis of a graph.

Now we can use this graph to help us identify bad/good duplication and bad/good code reuse. Let’s see how things fall into place and how software entropy does its best to mess things up.

Bad duplication quadrant
Ambiguous duplication is bad duplication, it’s the kind of duplication that will cause most harm, usually done in a “no tomorrow” mindset. Developers under time pressure are prone to fall into this trap. Same for less experienced developers trying to impress by delivering things quickly. Bad duplication is very appealing, just “copy some code over and get things done”.
Good duplication quadrant
Duplication combined with contexts is the good one, it’s the conscious decision that you’ll have more problems sharing code or data than maintaining two versions of it.
For example by duplicating some data over two independent systems you might have some extra work synchronising them. It might sound bad but what if in practice this means less work than forcing two different systems to share data? You can make two systems share data by using the same database for example, however this approach will cause high coupling on the data level and might prevent you from evolving your data schema as changes in one system can break the other.
Bad code reuse quadrant
That’s the thing that made me write this article, it’s the ambiguous code reuse. Contrary to bad duplication it starts with good intentions, the developer is following good practices and wants to make a component which is as reusable as possible and in the process creates an over stretched component that will be hard to maintain because the more contexts it has to serve the more generic and ambiguous it will be. In the end this component will be filled with conditionals and returning too much data. Any change to it can cause a cascade of errors downstream because of high dependency from other components, plus the fact that reuse multiply dependencies, it’s the Code Reuse Abuse.
There are some rumors that code reuse abuse is one of the reasons of SOA’s falling popularity. SOA focus on reusable components was easy prey for the entropy pull. The more generic a component is the more patching it will need when serving different contexts.
Good code reuse quadrant
Code reuse has many faces: shared libraries and shared components are the obvious ones, there’s also code reuse supported by programming languages like inheritance, traits, mix-ins. Things need to be shared and reused right? It’s a good thing 80% of time, no question about it.
So what’s good code reuse? It’s a bit hard to say because code reuse has a sweet spot. Reusable code needs to be generic but just enough, otherwise it risks becoming ambiguous and causing more harm than good. Developers with a single perspective in mind are easily pulled towards bad code reuse because it’s easy to miss the big picture when you’re focused only in one thing, it happens to everybody.
Wrapping it up, back to the wind window!
So now we know the software wind window and its power zones, and we also know that we can’t keep the kite only in one place or it loses power and crashes into the water. So how can we harvest the software wind window and actually surf? We do figures of eight on its good quadrants! The article is about balance, looking for appropriate duplication and code reuse, knowing how to spot them. But like gravity, software entropy will never cease to be, just make sure the kite keeps moving in the right quadrants. And if the kite does veer to the bad quadrants, get it out of there, fast!

