You can fight entropy, but it's embrace is all but inevitable in large enough teams (measured by total having worked on a codebase, not just those currently working on it). It's just entropy and software's lack of real world constraints played out. You can keep cleaning but you're fighting a loosing battle against physics.
Not only that, but the second law actually implies that not only is cleaning a waste of time long term, but letting complexity spiral out of control also counter intuitively imbues the software with a competitive advantage. Namely that trying to EEE or clone a convoluted messy system is much harder and therefor more expensive.
I'm not really sure what to think about this. Obviously I don't like it. I'll probably keep tilting at windmills for a while.
I love playing out these situations and constantly seeing just how badly globalism has left whole countries hollow. I quipped a few years ago to a coworker when discussing economies that you can't eat data. That an economy built entirely on service jobs might have some structural issues. Based on their reaction I worry things are probably going to get a whole lot worse before they get better.
Really great stuff in there for anyone building linting tools. One of my favourite things about linters is that they force you to flag individual lines of code as knowingly problematic. Rust's unsafe block is a fantastic idea. For example, any time I want a global variable, I'm forced to add a little comment to acknowledge that this is generally a bad idea. It communicates clearly to others reading that I'm doing something that usually causes problems. Then we can have a discussion about whether or not my choice is a good one.
I'd love if we could get better data into linters that help clarify what we actually know causes problems and what things are just somebody's opinion without substance. Like if each entry had an empirically measured effect size. Then I could trivially tune the linter to pick the level of complexity reduction that seems appropriate to my use case. Honestly, just any empiricism in these tools at all would be nice. For now at least, rules can be turned on and off in a way that improves discussion among practitioners.
This so neatly summarizes years of experience in building and maintaining software in an essay that's likely straight forward enough for non-experts to grasp. It's fantastic, worth a read, and likely worth sharing.
Great deep dive on the resource management systems in the aviation industry. It's always fascinating to me learning about all that's going on behind the scenes in systems that make huge amounts of that complexity their problem and not yours.
