Physical Analogies · These are questions for wise men with skinny arms

Physical Analogies

After my last ramble-rant, I read two amazing pieces that tackled the same subject from different angles and far more succinctly. The first was to write disappearing software, to delete customizations as often as possible to eventually not maintain anything. The other was about outgrowing a standard layer and creating a perfectly customized layer. I loved both of these because they were specific and actionable. They both talk about specific layers and take the embrace of layers as a requirement, which still gets push back from some communities with all of the reasons I tried to talk through previously. I think this shows a fundamental difference in the philosophy of engineering software.

When we think about the amazing progress in computing technology compared to other young fields, one of the biggest is that internal computer automation has been wildly successful. The level of abstraction and common tooling has enabled smaller solutions to solve bigger problems with increasing less training. I consider this a massive win for society, technology proliferation enabled by industrialization at a scale that is barely held back by physical limitations. There are downsides of course to this level of expansion, the concerns of security, quality, and longevity continue to threaten this progress if left ignored. This level of enthusiasm in face of the perils isn’t shared by all practitioners, many pushes against this commoditization, instead opting to praise the hand-tooled or boutique. These projects have their place to teach fundamentals and refresh aging solutions of the same kind, but they sometimes lack the eye towards the scale that made the tool possible in the first place.

Street Paving

The streets on my commute have been undergoing a resurfacing and with some historical reframing, it’s a great analogy for the evolution of a system with automation at play. Early asphalt roads were done entirely by hand, hundreds of people doing backbreaking labor for months literally paving the way for future progress. As the process became popular it attracted the creation of many tools to enable worker efficiency, each a small step to save time or cost. Now there is a nearly standard set of tools and processes that allow an unbelievable amount of the earth’s surface to be covered by the stuff. It’s a tremendous achievement that everything from the foundation design to the materials has been so heavily optimized to the machinery that hand-tools are only a common sight to passerby because the machines finish so quickly. For the parts that do still require manual intervention, history rather than current technology better explains the process. When roads are resurfaced, if they weren’t built with the current generation of machines they require humans to do things like cut out space around sewer covers. They are infrequent enough that most machines don’t have a special mode that would justify the cost complexity, so they are left to guys with jackhammers and shovels. Other sections of road are too steep, too narrow, or too curved to be done at all. These missing features all have something in common, they were all once done by hand and now continue to require that same touch. The amount of work in creating these custom road features was completely required and deemed entirely necessary at the time, but now the choice is to either make a very complex paving machine to deal with this or to replace all of the existing road covers into a shape that the current tools can address.

Say you’re an engineer responsible for paving who sees this as inefficiency and tries to address it. You probably have other very important projects on your plate, so to prioritize you estimate a payback period for optimizing tools for the problematic roads in your area. You think it would take thousands of manholes over the decades to be worth the millions that an all-in-one paver RFP would require. So you shelf the project and continue shoveling, but that’s not the end of the story.

It sounds like this is a classic example of ‘worse is better’, where the paving tool company never made a machine that could do everything. There are probably a dozen other things to improve before getting to that comparatively high-cost low-reward feature. But then will it forever be done by hand? When other special purpose manhole paver cutters are made to fill this gap, is that the best solution? What one engineer sees as an inefficiency, the other sees as the right thing to do. The problem is that for every decision made to continue digging by hand, it only becomes harder to make paver that can handle even more customizations. It’s hard to tell if digging is then advancing the project or holding back future progress.

Determining the right thing to do for an engineering project is entirely a matter of perspective and context. For the physical example, it might not be obvious what’s easy to do by hand vs machine. Even when it can be generally agreed upon, it might be nearly impossible to accomplish in an expected way. The initial design that sounds so promising might not be as good as sticking to shovels. I’ve seen so many projects go wrong in both directions for this. Either the engineer is unfamiliar with the field and attempts to combine two standard pieces into something that sounds more efficient, but due to its custom nature is not worth the hassle. And I’ve seen uninterested engineers do the equivalent of digging holes by hand over and over again when there are tools that avoid the work entirely. In my experience, the right things are rarely done as expected and the things done as expected are even more rarely the right things to do. I love how contradictory that sounds because it requires a clear division between the right thing and a correct way. It’s so philosophical, separating the ends and the means and evaluating them against different criteria. It’s such a common concrete problem that if you don’t address it explicitly, you’ll conflate the two and get very confused as to why something didn’t work out.

Many engineers have this idea of beauty, of a simple complete solution that’s both rewarding to build and beneficial to the industry, so they strive for it. Others are convinced by their own estimates of time saved vs effort and forsake the beautiful solution as wasteful compared to their easy fix. It’s a strange dichotomy of hubris and impatience. Either you think you know how to do things right, or you don’t care enough about how you do it and just try to get it done. A reasoned compromise becomes difficult when you often have to sacrifice one side for the other. The right choice then requires some digging on either side just to find it.