Another Software Systems Plaint
Back in the 80s, I worked in Aerospace and had an old engineer tell me “nobody’s really figured out how to write software.” I scoffed. Totally ridiculous, I thought. He was researching a transition to Ada. I was writing tons of C code.
Now, much older, and perhaps somewhat wiser, I see his perspective. We’ve developed a lot of ways to try to deal with software. There are different approaches, with principles of abstraction, structure, and documentation. I tend to believe that most software methodologies are too discrete. Once you’ve maintained an active codebase for a business over a few decades, you discover that software design principles are great for coding but bad for business. It’s very difficult for a coder to understand which aspects of a business are virtually immutable (“the canonical catalog is Bob’s PDF notes from his meetings with manufacturing”) versus things that change (“yeah, we computed sales bonuses this way for the past twenty years, but now we’re changing that on a quarterly basis”). Often, the people running businesses don’t consciously know these unwritten laws themselves, and only reveal them when a change is suggested. Heaven help you if the change was implemented somewhere first.
Methodologies for business and software come and go, whether they’re TQM or Agile or just “move fast and break things.” I definitely see the advantages of the tendency away from front-loaded planning and towards flexibility and accepting change, but it doesn’t do a good job of managing the complexity of history. How do you maintain and document all of the Chesterton’s Fences in a continuously evolving codebase? When new components are bolted on to older systems, you accumulate a lot of weird adapters to make things fit. Sometimes, intermediary components go away, and you’re left with layers of adapters between things. Eventually, the solution might be the same as it would be for an analogous plumbing problem: rip it out, and start over — but, to overextend a metaphor, when the system is a million lines of code instead of a few thousand meters of piping, the solution may end up replacing the entire building so you can install a faucet.