// Evading Software Entropy

I've been thinking quite a bit recently about how effective software projects are managed. In previous posts I've talked about my thoughts on limiting the code you write to just what you have to write. The more code you have to maintain, the worse off you are, yet every project has to have some code. So how should that code be written and managed? No one sets out to write bad code but actively developed projects seem to head invariably in one direction: toward chaos. How fast your project experiences entropy depends on several factors but the most important factor seems to be how seriously you take staving it off.

In a post on the blog Joel on Software dated all the way back to April of 2000, Joel Spolsky argued against this idea. The article primarily warns of the evils of restarting a project from scratch, calling it "the single worst strategic mistake that any software company can make" and I somewhat agree with that idea, but supporting his argument he states that code does not rust. Instead, in his view, code grows more complex because it's battle-hardened. It's been used, tested, patched up, and every line represents significant investment in fixing buts and making the product work well. So why is old code so ugly? "It’s harder to read code than to write it," he says. This is why older code inspires the urge to start over, he claims, but this is where I disagree.

As software projects grow and evolve, things tend to get messy, and it's not entirely from being battle-hardened as Joel indicates. Many things contribute towards the entropy of source code and bug fixes, I argue, are not one of them. Instead I believe the primary cause of entropy is human fallibility. When a project is first conceived and architected, effort is made to ensure the design is flexible and scalable. Hopefully it can handle whatever new ideas and unanticipated features you can throw at it, yet even before the first line of code is written, your design could contain mistakes you don't see. Then as you begin to implement the design and later when you're building new features upon it, you're at risk of making mistakes every step of the way.

The client wants feature A now, so you compromise your design to implement it quickly. You set out to implement B and overlook an opportunity to refactor something to make B a better fit. A new junior developer joins the team and makes rookie mistakes that no one catches. All these and more work to make your code harder to read, maintain, and extend. Eventually you find yourself so frustrated with the state of your project that all you want to do is start over from scratch. Is this simply because code is harder to read than to write? No, it's because you're human and your code suffers for it.

So should you start over from scratch? No, that's probably a bad idea, but what you can do is learn from your mistakes and embrace processes and techniques to mitigate entropy going forward such as SOLID design principles, unit testing, and Agile software development. I'll explore some of these in future posts as I endeavour to become more familiar and experienced with them in practice.