Skip to main content

Complexity equals Entropy?

Posted by mlam on November 29, 2006 at 1:10 PM PST

Gotta get some work done. So, short entry for today. CVM Internals will have to be postponed again ... sorry. On to today's topic ...

2nd Law
The second law of thermodynamics states that [at least how I would like to remember it] ... universal entropy always increases. An interesting corollary of that is ... local entropy can be reduced by infusing energy, but this also comes at the cost of increasing universal entropy. I probably butchered that in so many ways since I'm not a physicist. But let's get to the point ...

Software Complexity
Software complexity is a bit like entropy. Over the lifetime of a software product, there will be enhancements, customizations, ports, etc. All these add to the complexity of the code. We all know that complexity makes it harder for us to maintain the code. After all, the human mind can only remember so many things at a time. Too much complexity, and we'll have trouble maintaining the code. Bugs start to creep in. It takes longer and longer to add new enhancements without breaking the system. When your buddy who wrote half the system decided to leave for another job at a startup, you are left in charge of the code. Congratulations, you are now the new governor of a territory (the code) infested with wild beasts (the perpetual bug parade) without a map, and top it off, if you don't get the territory under control soon, the king (your boss) will have your head.

What to do? What to do? ...Taming Complexity
One approach is to simply not add features to the code base in the first place. Less features means less complexity. This approach actually works and should be a motivation for us to not add superflous features to our code. So, you get away with that for a while, but the boss says ... "No can do!". Drat!!! That marketing dude's been whispering sweet things in your boss' ear again. So, on to the next option ...

Fight Fire with Fire
You add more complexity in the form of organization. This means you make sure to apply good development techniques like structured code, object-oriented methodology, design patterns, etc. Instead of one big piece of spaghetti, your code base now looks like a work of art. And you can literally paint pictures (and draw maps) about it too. And you don't feel so lost anymore. Though you can't remember every detail about every nook-and-cranny in the code, you have the BIG Picture ... the map ... aka the architecture ... aka the system abstraction. And this map is a lot easier to remember than all the lines of code in the system.

But hey, did I not say that complexity is bad? All this OO and architecture stuff ... it all adds complexity too. And it incurs code space to implement all that fancy polymorphism and what not. The answer to that is undeniably yes. All this extra code organization does add extra complexity. If you are to chart out the system now, there are a lot more boxes and lines than before. But the difference is that when you're working in a sub-component of the system, your boundaries are a lot more defined thanks to all that organization. As a result, you only need to be concerned with the small set of information about that sub-component. In contrast, before all the organization, you are exposed to the information of the entire system. Without some organization, that sheer volume of information is just over-whelming. And this leads me to my point ...

Local complexity can be reduced at the cost of global complexity.

... and we would want that. In practice, we only work on one local area of the code at any given moment. Bugs are also introduced while working on the local area. If we can reduce local complexity, we increase our chances of not introducing bugs, as well as being able to maintain the code better.

The last thing to note is that (just like in the 2nd Law), reducing complexity costs energy. In this case, that energy takes the form of effort on our part. The code isn't going to just organize itself.

the End
And that ... is my Law of Software ThermoDynamics that I cooked up some years back. With my luck, chances are someone else probably came up with the law independently years before I conceived of it, and I won't be able to get credit. Anyway, I thought you might enjoy that little perspective.

Happy coding. :-)

Related Topics >>