Do you feel like you're pushing out one tangled pile of software after another? Or, fouled by experience with spaghetti code, do you endlessly polish, searching for that future-proof metaphor? Both roads lead to headache.
Software engineering is partly the act of writing code for our present needs — the feature that improves conversion or the bugfix that prevents the annoying on-call page. It is also the act of writing code for our future selves; when we're deep in some system that hasn't been touched in six months and wondering who in the world thought this structure was correct. It's often you. It's often me.
The tension between present and future, speed and maintainability, is a source of stress in engineers and engineering organizations alike. Too quick now and the future project is bogged down by hard-to-extend code and fails. Too deliberate now and there is no revenue for future projects.
A quote has followed me throughout my career. Carl, an exceptional software engineer that I had the pleasure of working with, once remarked that "all code is technical debt." Anish Kapoor shaped steel into Chicago's Bean, but mostly we use steel for i-beams and bolts. A function may be aesthetically elegant, but mostly we're writing infrastructure for CRUD applications.
It's said that anyone can build a bridge that stands, but only a good engineer can build one that just barely stands. To create an application that just barely executes we have to build it on the right structures. Good engineering requires an understanding of the systems we're working in. It requires technical discovery and forethought. It also requires that we don't overbuild.
Code facilitates value but is not itself valuable. It's the tension cable and the reinforced concrete slab. It should be well designed, but we know that it must also be maintained. A lean system has less technical debt, less surface area to rust. We build just enough to get the job done, but we do so in acknowledgement that we'll return to work here again.
I've given up foretelling how to build perfect software, so these ideas help me in technical discovery, in planning, and in execution. I spend my extra 20% effort to get a metaphor that feels about 80% correct. I thank my past self and find joy in factoring a little better while extending that work six months later.
All of the best answers are the frustrating ones: it depends; it's about the feel of it; it's not at the extremes but somewhere in the middle. It helps to know that a little work now is worth it in the future.
Thanks for your time and attention.