Software system design's got it pretty good

Now that the nightmare of finding a new home in a broken market is over... I'm currently neck deep in hiring people to do various necessary upgrades before I move in (1950's electrical wire says hi!). I've become pretty fearless in terms of DIY home repairs and upgrades by now, but upgrading entire rooms and systems is a complete new experience for me.

The thing that I wasn't fully prepared for was how a home is a giant interconnected system. I knew this on an intellectual level, but I didn't fully appreciate what that meant until now. If I want to replace the ancient cloth-insulated wire running throughout, I'd have to punch holes in the plaster (!) and lath to get to it. I can patch those holes up once the electrical work is done, but if the plumber is going to come back with a sledgehammer again later to do something to a water line, maybe I should just hold off patching and painting if I know it'll happen soon.

Joists supporting the upper floors run in the ceiling a certain direction, a decision made by some unknown architect a century ago. They are now forcing me to run ductwork in a certain way, which had a surprisingly huge effect on where I put anything in the kitchen. Upgrading an HVAC system means finding room to allow for ducts and vent holes, which forces other walls or cabinets to shift, which shifts some plumbing and wires.

It's a giant interconnected mess that requires having a working knowledge of all the pieces together, with some quick thinking and flexibility to solve design issues when they inevitably arise.

Software can be like this, especially very large software projects. That's why it's called an "engineering" discipline. Architectural decisions can have deep implications for subsequent designs many years down the line. It's also certainly possible that making some changes to one bit of code can have cascading effects on lots of other bits of code – this is what refactoring is after all.

But what struck me about figuring out how to upgrade things on this house was just how... decoupled good software architectures can be. We can add many many layers of abstractions, shims and APIs to make ill-fitting pieces of software work out. These bits of bridge software are relatively cheap in cost and time to write and they get us out of all but the most intractable software issues.

Such luxuries aren't true of physical machines and spaces where the laws of physics, economics, and building codes compete to foil your creative efforts. I've spent more time the past couple of days figuring out why a hundred design ideas or products won't work in a space because they collide with design constraints inherited from some decision by a person long gone. Many of those decisions can't be easily changed without demolishing something else that sets of even more design considerations. If I'm not careful, the chain reaction of consequences could easily lead me to deciding to just demolish the whole building and start anew.

That's not to say that doing these targeted renovations, a.k.a. refactors, isn't possible. It just takes so much more work and juggling alternatives than starting fresh. If anything, it's a bit of testament to the creativity of folk who have to work retrofitting solutions to 50, 100, 200 year old buildings around the world with modern conveniences without destroying everything in the process.

Another interesting thing I learned is that chasing perfection inevitably leads to wanting to tear the whole building down and starting over. Since that's obviously infeasible for a very expensive building, the trick to staying sane is to learn to accept that some things are outside of scope. For example, maybe that single ancient cloth-wrapped wire that goes to a light (and only a single light) can stay as is because so long as it doesn't move it's not going to get damaged and become an issue. Yeah the door is crooked but it at least opens and closes and we most definitely don't want to hang a new one because that opens another chain reaction.

The same should apply to code too. As I mentioned, the vast majority of software we work on isn't nearly as tightly coupled as even the simplest of buildings. Some improvements and refactors just aren't in scope today no matter how much that imperfection is singing to us with its siren's song. We can't fully anticipate what knock-on effects changing that piece will have, so let's not do it today.

There's always time for another //TODO.