Software Engineering Is Not Over; It's Only Just Beginning

What’s In a Name?

My grandfather was a plumber. Correction: my grandfather was the best damn plumber in his North Jersey suburb of New York City, and everyone in town knew it. He had ten kids, six of them boys, and as my father and his five brothers grew up they all, at one point or another, ended up being employed by my grandfather as plumbers. Most of my uncles eventually moved on to other professions. One of my uncles still runs Ballanco Plumbing. Then there is my father, who left the plumbing business but not the plumbing industry. He would go on to university and get a degree in Mechanical Engineering, eventually specializing in Plumbing Engineering and becoming a world authority in the subject (more on that a bit later).

Growing up I had always wanted to be a scientist. When I was 12 years old or thereabouts, I asked my father about the difference between scientists and engineers. He told me that, “scientists discover, while engineers build.” When I entered university as a Chemistry major, the same university my father attended for his Engineering degree, I remember he told me that, “Any fool can build a bridge. It takes an engineer to build it on time, under budget, using the least amount of materials possible.” Eventually, I would return to the same university, this time as a graduate student, and receive my Ph.D. in Evolutionary Dynamics. By the time I graduated, though, I had already been simultaneously employed for a number of years at Apple as a “Software Engineer”.

If I’m honest, that title has always bothered me a little bit. I graduated alongside peers who went on to become Chemical or Mechanical or Electrical or Civil Engineers. After they graduated they had to take a six hour exam¹, then gain at least four years of professional experience, then take an eight hour exam² before they could call themselves an “Engineer”. All I had to do was pass an interview demonstrating that I knew how to code. For this reason, I’ve never really known how to respond when people ask me what it is that I do for work. Usually I’ll stammer something about how I’m a coder, but my title is “Software Engineer”. In my own mind, I always thought of myself as a “hacker”, but of course as a professional title that carries unwarranted baggage.

Over the years my title has changed from “Software Engineer” to “Senior Software Engineer” to “Staff Software Engineer” and eventually “Senior Staff Software Engineer”, but always that term, “Engineer”, was attached, and always it felt unearned. This wasn’t imposter syndrome, but rather an unease with the relative lack of rigor that the “Software Engineering” world practiced as compared to all the other kinds of “Engineer”, and a concern that someday that might actually matter.

When Craftsmanship Is Not Enough

Growing up with a father who is a Master Plumber³, I of course learned a thing or two about plumbing. I was still in middle school when I learned how to solder a copper pipe, and how to make it look good. I helped replace water heaters, and learned how to seat a toilet on a wax ring. (Those last two skills came in especially handy during the COVID lockdowns when I had to do both on my own.) I did all of this with my father not out of necessity, but rather out of his earnest desire to instill in me the skills his father instilled in him. In his job as a Plumbing Engineer, the one thing he was pretty much never asked to do, ironically enough, was plumbing.

Instead, being a Plumbing Engineer requires much more systems thinking. Instead of worrying about how to join two pipes or finding the source of a leak, a Plumbing Engineer is concerned about capacity, pipe sizing, vent stacks, and ensuring that sewer gas doesn’t enter a building or that contaminated water doesn’t find its way into the fresh drinking water supply. I remember in university us Chemists would often refer to Chemical Engineers as the “Accountants of the Chemistry World”. We weren’t that far off.

Of course, Plumbing has existed as a profession far, far longer than Plumbing Engineering has. Indeed, the term “Plumber” traces back to the Latin for Lead (Plumbum), the preferred material for water pipes in the Roman Empire. It is not as if the problems that Plumbing Engineers solve sprang into existence when the first plumber traded his coveralls for a pocket protector and appended the title “Engineer” to his business card. It is also not the case that, when you call a plumber about a leaky pipe or clogged drain, he must first consult with a Plumbing Engineer before solving the problem. My grandfather replaced many a water heater and connected many a house to his town’s new sewer system without, to the best of my knowledge, directly consulting with a Plumbing Engineer.

And yet, my grandfather benefited from the practice of Plumbing Engineering every day of his career. When he consulted the ratings on a water heater to figure out if it would supply enough hot water for his customer, it was a Plumbing Engineer who calculated those ratings. When he was granted a permit to connect a house to the new sewer, it was a Plumbing Engineer who figured out that the system would have the capacity to add another house’s sewage. When he installed a toilet or even soldered a pipe, somewhere there were Plumbing Engineers working behind the scenes, ensuring that standards were being upheld and compliance testing was performed, so that every customer my grandfather served could live with a safe, healthy, and reliable plumbing system.

So in one sense, the practice of engineering exists to enhance the craftsmanship of the skilled tradesperson. Engineering also exists to prevent things from going wrong. There’s a saying in the world of engineering that “regulations are written in blood”. Indeed, if you look back at the history of the practice and development of engineering, many advances and new standards in how engineering is practiced are preceded by an unfortunate tragedy. So in a very real sense, engineering is not just involved with thinking about physical systems, but also human and political systems. What sorts of regulations are needed, how should they be enforced, and when can exceptions be made are all considerations engineers grapple with right alongside the realities of fluid dynamics or materials science.

There Will Be Math

Lately, I’ve been thinking a lot about my grandfather and father, about Plumbing and Plumbing Engineering; not because I’m contemplating a career change (though I hear the money is pretty good!), but because I feel like the time is ripe to make good on those titles I’ve carried around my entire career with mild discomfort.

Recently my wife and I bought a house that was in desperate need of renovation. We went all in, including having the plumbing system completely replaced. When the plumber arrived and began stringing PEX throughout the house where the old copper pipes used to run, I called up my father and complained. “Can you believe it?” I started incredulously, “They’re replacing all the old copper with this plastic stuff…what would grandpa think?”

“Oh,” came back the calm reply, “yeah, that’s what everyone is doing. I just helped your cousin design a whole PEX system for his new house. It’s progress…”

And indeed, it is. Without getting too into the weeds, while copper is great, looks good, and lasts a long time, PEX is better in just about every way: cheaper, faster to install, easier to service. While I never gave too much thought, day to day, about my ability to solder a copper pipe and make it look good, I felt a small twinge of pain realizing that this esoteric skill of mine would never be useful for any serious work again.

It’s that same twinge, of subtle remorse mixed with a touch of nostalgia, that I feel when looking back at the last year or so, and realizing that I almost never write code on my own anymore. No longer is my skill in being able to balance Clojure parentheses blindfolded, or knowing the exact sequence of symbols to golf a Ruby iterator, practically useful. All the beautiful code I’ve written over the decades now stands alongside my grandfather’s beautiful copper pipe solder joints as relics of a bygone era. At the same time, it’s hard to feel too sad about the state of things. We likely saved significant time and expense on our home renovation with PEX, and I can now wield multiple LLM agents to ship software features faster and at a higher quality than I ever could before.

The reality is that, if we learn the lessons of the plumbers, electricians, and bridge builders that came before us, far from this being the end of anything, it is merely the dawn of “coding” graduating to become, truly, “Software Engineering”. What this will mean for those whose skill with code was the primary value they brought to the development of software is, well, predictable. For those of us who always thought at higher levels of architecture and design, and wrangled code as a way to achieve those visions, we have the opportunity to define a new field. What this will require is formalization of those thoughts, designs, concerns, and intuitions we have all relied on for so long into proper standards, regulations, and certification criteria. We may even need to dust off our copies of “Design Patterns: Elements of Reusable Object-Oriented Software” or “Structure and Interpretation of Computer Programs”. It may even be, as much as it pains me to think about it, time to retire “make it work, make it right, make it fast” and “laziness, impatience, and hubris” in favor of rigor, analysis, and planning.

A Golden Opportunity

If we lean into this transition, however, the field of Software Engineering has an opportunity in front of it that Mechanical, Electrical, Civil, and Chemical Engineers could only dream about. In all these other disciplines, there is a disconnect between the thing as designed and the thing as implemented. There is a term common across all these fields: “as built”. What it refers to is the deviations between what the engineer planned and designed for, and how the plumbers, electricians, and construction workers dealt with the realities of sourcing materials and the challenges of building in the field. All too often, the blood that inked the regulations developed for these fields was a consequence of these deviations⁴. A not insignificant amount of time, effort, and thought in Engineering goes toward how to account for the “as built” reality.

But with software we have the opportunity to make the design and the implementation one and the same. We can close the gap between what the engineer intends and what exists in the real world. Software may be the first engineering discipline in which the designs, specifications, verification, implementation, and deployed artifact can all exist in the same substrate. In that sense, Software Engineering has the opportunity to become the first “pure” Engineering discipline. To get there, though, we will need to shed many of the “best practices” of our code-as-craft era. A Plumbing Engineer does not judge the quality of an “as built” plumbing system by admiring the quality of the solder joints, but by running the numbers of what was actually built back through the same equations used in the initial design, and comparing the results to the limits and tolerances derived from years of testing and, yes, regulations written in blood. Similarly, it may be the case that the code review, TDD spec, or end-to-end CI pipeline are no longer sufficient.

Life is funny, sometimes, and despite many accomplishments over his career that my father can rightly be proud of, the one thing that has brought him the most renown is his work on exploding toilets. As the story goes, new regulations on water use forced manufacturers of plumbing fixtures to devise new ways of flushing a toilet with less water. One manufacturer approached this challenge by devising a mechanism that would pressurize the water used for flushing. At some point, some of their toilets exploded, and it was up to my father to determine if the fault was with the mechanism or with how it was installed.

So my father returned to Stevens Institute of Technology, our shared university, where extensive research had been historically done into the nature of plumbing systems, especially in high-rise buildings. There, utilizing the lab facilities and some high speed cameras, he was able to prove that installing these toilets and failing to bleed air out of the system could result in the water used for flushing being accelerated to literally hundreds of miles per hour during a flush. When that high-speed water met the porcelain of the toilet, well, the results were catastrophic.

In other words, my father utilized the scientific method and discovered something new. He was then able to use this new knowledge and apply it to the practice of plumbing, ensuring that no one else would have to suffer the unfortunate consequences of a few unlucky individuals with brand new low-flow toilets. It turns out that engineers do build things, but they also discover things along the way.

I am looking forward to a new dawn for software. I am looking forward to discovering new knowledge about how to build systems that are safe, reliable, and efficient. I am looking forward to, for perhaps the first time, being a Software Engineer.