Of Gardening and Engineering

We build our computer (systems) the way we build our cities: over time, without a plan, on top of ruins.
- Ellen Ullman

Lately, I find myself thinking back to a decade long argument on whether computer industry should be considered engineering or gardening. For those unfamiliar (or young enough) — when Chris wrote the article in 2011, it started a holly war argument, manifesting itself (pun intended) in Software Gardening Manifesto. Full disclosure, I was always on the engineering side of the argument. I find the more “flowery” argument to have limited, to say the least, understanding of both software and civil engineering. Eleven years later, I am (arguably) more mature and (certainly) more experienced. And it is worth revisiting the conversation to define the software industry as it stands for those entering it.

Let’s define “software engineering”

First off, let me start from the perspective that bothered me perhaps the most — the whole “gardening” argument is based on Agile process foundation, indirectly assuming relation to web application development. Which is not, I repeat, is not the same thing as software engineering. It is merely a subset of it. Growing most visible to public, but rather small subset. Other subsets of software include things like, you know, air control, military equipment, space program. Things that have a finite scope and rigid resilience, unlike “endless environment reform”; things that do require “insane degree of accuracy”. Simplifying software engineering to web development is like simplifying civil engineering to building tree houses. Both require similar skill sets on the surface, but the requirements and the impact of failure differ significantly.

Civil engineers are not perfect

The whole concept that civil engineering projects are “done” is as flawed as the same argument applied to software. If the projects were done, we wouldn’t see a decade long Route 50 widening project driving into D.C. (and speaking of “decade long” — this is where the whole “That’s how Engineers roll” with precise estimates argument falls apart too.) Or anyone living in NYC would enjoy a stroll down the Brooklyn Bridge without the background noise of jack hammers. Civil constructions require ongoing maintenance and repair. This is an axiom. And there are more than one reason.

• wear and tear — asphalt needs to be repaved on the regular basis and building set and need to be re-caulked and repaired. Sometimes using duct tape (shoutout to The Leaning Tower of Pisa). National monuments are being services on schedule, with some of the major repairs scheduled routinely. The more critical (read: dangerous in failure) or used (highway pavement) the structure is, the more ongoing wear and team maintenance it requires.
• capacity/growth planning — when cities were built they were not planned for exponential growth of the population, never mind the exponential growth of the population with vehicles. NYC boroughs are the perfect example of cities that have long exceeded its capacity. Tasks like widening of the roads and rezoning of neighborhoods are just in a days work for civil engineers, in order to accommodate for growing car traffic.
• pattern changes — every change forces a chain reaction. When VA extended it’s metro line, new business centers were built, requiring updated roads (accommodating for new traffic flows and capacity), rezoning for recreation centers, community facilities and commercial traffic. All that without the (major) sacrifice of quality of life for existing housing and businesses.
• outdated requirements — and speaking of D.C., which was built in a most confusing way to prevent invading army from reaching the Capitol. I don’t think it’s really a top concern in 2017.

If, as a software professional, the list above sounds familiar to you, that’s because it should. Those are the exact reasons why we have to maintain, troubleshoot and upgrade software systems. Oh, wait. I forgot one.

There are C students in engineering classes too

Granted, the learning curve for web developer is significantly less steep than the one for skyscraper architect. That said, a) see Let’s define “software engineering” above and b) “the lowest bidder can probably build the same bridge as the highest bidder,” but that word “probably” is a potential qualifier for making a Top 100 list. As with software, the higher the magnitude of the failure scenario is the more rigorous the quality control, but to claim a 100% accuracy is just ignorant. Conversely, failure in engineering and architecture doesn’t have to be fatal (again, much like in software). Designing a 2-way street with a sharp curve in a middle was probably fine on paper, but with cars parked on both sides of the street, it creates an eventual statistical leader in accidents. Same can be said for intersections with parked cars/trees/etc. blocking the clear street view. There is a reason you can’t turn right on red in most boroughs in NY (speaking of retroactive duct tape fixes).

At the end of the day, the titles are just semantics. You can call it engineering, gardening, cooking, even sheep herding — I don’t particularly care (chances are I’ve been called worse). What I do care about is misrepresentation of a skill that others may take as a basis for their professional development. Software profession has a lot of different branches, each with different regulations, requirements and tolerance for errors. Building Wordpress website for a gym, software for high-frequency trading and protocol for air traffic control are not the same thing, even though it can all be placed under “software development” umbrella. So, take argument such as this with a grain of salt, understand the space you’re in and don’t let opinions get in the way of the facts.