Additive Vs. Subtractive

There are two basic ways to make colors, additive and subtractive. Then there’s positive and negative space. M.C. Escher loved to play with positive and negative space, and you’ve probably seen the vase/face image. Michelangelo is said to have said that the sculpture is already inside the marble, he just removes the superfluous stuff.

But what has this got to do with software? We write software, we don’t carve it. We don’t start with a wall of text and release the program hidden within it. Or do we?

It’s been said that programming can be the art of adding bugs to an empty file. But most of the time we don’t start with an empty file, or at least without a framework we’re working in, so it’s not purely additive. In fact, a big part of what we do is work within the confines of existing code/systems.

This is most apparent when we come across something new. A common task for someone new to a team is for that person to take a bug off the list, figure out what’s wrong, then fix it. By its very nature, that’s a subtractive task. Remove the bug. And often the best way to do that is to remove a bunch of complex, brittle code with something simpler that fits the current data/processing model better.

Or consider a system where there are N ways of persisting data. Not just N places for data at rest, but N completely different ways to get the data there. Somewhere, hidden inside those N ways, is a much smaller number of ways that you really need. Ideally one. So subtract a few of them. Then there’s only one thing to maintain. One thing to update when the business/data/processing model changes. One place for bugs to hide instead of N.

So next time you’re presented with that wall of text and a problem to solve, don’t just reach for another empty file. See if you can release the masterpiece that’s hidden in that wall of text.