On architecture, urban planning and software construction

As I read Tomas Petricek’s On architecture, urban planning and software construction, it reminded me of an interesting point Dan Luu made in How (some) good corporate engineering blogs are written: “There’s a dearth of real, in-depth, technical writing, which makes any half decent, honest, public writing about technical work interesting.” Tomas’ piece reminded me of this not because it lacks substance, but rather for the opposite reason: his work stands out as a prime example of substantial technical writing. I recommend reading the entire piece, but I will highlight a few interesting points here.

First, on good software design:

“In Notes on the Synthesis of Form, Christopher Alexander points out that design always speaks of form and its context. A good design is not just a property of the form, but it is a matter of fit between the form and the context. The reason why we cannot evaluate an isolated form is not because we are unable to precisely describe the form itself, but because we are unable to precisely describe the context with which it will interact. ... Exactly the same limitations exist in the world of programming. No matter how precisely we can talk about programs, we also need to exactly understand the environment with which they interact. This is the hard part.”

The idea that suitability determination involves a multi-dimensional performance assessment on a scenario-by-scenario basis, rather than a simple checklist, is a departure from the process I often see. This approach represents a more complex process, and even a more fraught one, too — but, perhaps, also one that might deliver something usable.

And then on the unintended consequences of avoiding maintenance, later:

“When discussing maintenance, [Stewart] Brand mentions the cautionary tale of vinyl siding, which is used to avoid problems with peeling paint. Rather than repainting a wooden wall, you cover it with a layer of vinyl siding, which is durable and weather resistant. The problem is that vinyl siding blocks moisture and the humidity behind it can cause structural damage to the building. Many traditional materials have the attractive property that they look bad before they act bad and, furthermore, the problems with traditional materials are well understood. ... The lesson about using traditional materials has a relatively easy parallel. If you build software using tools whose problems you understand, you will be able to expect and resolve those problems. If you are using a new material, you will not anticipate where problems might occur.”

To once again pound the drum I just haven’t stopped beating since Good Times Create Weak Men:

“By learning to use frameworks instead of the tools and protocols they implement, developers not only miss out on foundational knowledge that will help them become better at their job, but also hamstring themselves to the subset of features the frameworks’ creators’ felt important enough to enable. Expanding a project beyond that expected use case will require diving into those low-level tools and protocols.”

Mehul Mohan had a similar take in The Best Way to Learn Front End Web Development. I tend to have low expectations for articles that purport to have the answer, but Mehul delivered some sound advice:

“You see, frameworks exist to offload repetitive work from you. They do not exist so that you can not care at all what’s going on under the hood and rely on the fact that it’s all magic. The first time you choose a framework like React or Angular for your projects should be when you’re confident that you can create that project without React or Angular too.”

You should learn C not to use it, but because it will make you a better programmer. Learning C will help you understand the code that underlies your usable high-level language. node.js vinyl siding is cool, but do not ignore the old-fashioned tools it “replaced”: we used — and still use — them for a reason.

Again, I recommend reading the entire piece.