What is Software Engineering

I’ve lately been trying to clarify what software engineering is. It’s initially logical to evoke and take ideas from other engineering disciplines, where maybe the same question of is it an art, a science, or a craft still exists. But in diving a bit deeper, the lines are fairly blurred, and many examples and practitioners exist within all engineering disciplines of each. What inspiried my writing this was mostly this blog post, and much of the following is written within it’s context.

To summarize the post, most of it discusses various models of software engineering, their consequences on the production of software, and considers alternatives, notably Glenn Vanderburg’s talk in which he dives into misconceptions on the general notion of engineering. Vanderburg describes the process of a traditional engineering discipline (such as architecture), where architects (designers) design and produce a document or blueprint that builders (coders) follow to produce a final released product. He then presents a different, higly idealized model where software architects design and produce a document (source code), that is then compiled, deployed, and released by the builders (CI/CD) to create the final product.

In the second model, the point is to emphasize that building and releasing is cheap (compared to traditional engineering) and is something that should be taken advantage of. Some companies certainly do - they’re called startups. Many companies, however, seem to aspire to be traditional engineers and are attaching extra processes that bog down the otherwise comparable advantage software has over other engineering disciplines. This point of emphasis, that software has the potential to quickly build up enormous amounts of reach for very little time invested starts to be a defining point for me. Compared to something such as creating the honeycrisp apple (which took 30 years to make¹), Instagram was founded in 2010, and took only a year to reach 10 million users, and is something many college students could build. From what I’ve gone through though, most college students are trained to just implment and care about various extraneous technical details (many of which are only really relevant at scale).

Bootcamps

To me, the rise of coding bootcamps isn’t signaling demand for software engineers, but for software builders within the traditional assembly line model, analagous to how an architecture firm might work with a construction company to create their vision. I’m imagining that most current bootcamps crams years of language, framework, or ecosystem syntax knowledge at the expense of system or design/product knowledge², and when companies are hiring for someone who has 5 years in Framework X or 3 years with Language Y, they’re not looking for architects who can juggle the needs and uses of a system, they’re looking for syntax knowledge, which can explain why most companies separate the role of designer and implementor/programmer, which goes totally against the idea that the one best able to understand what’s implementable doesn’t get to decide on what to work on.

Should architects know what goes into constructing a building? Of course! So why is that little bit of nuance skipped during the building of most developer teams? It could be the costs or waste of buggy software is much less, and the vision of what it looks like when gotten right is much more important, but then wouldn’t that reflect in higher salaries for designers?

Why can’t programmers design? It seems to me that the person closest to the code has the easiest time understanding its limitations, and the person closest to the user has the best understanding of how might something solve that user’s problems. Why then, are people playing a game of telephone from user to designer to developer? This could be systematic of American culture as a whole, where there’s a growing urgency to be well-defined and self-explanatory in order to differentiate or specialize. Or it’s the symptom of an educational system where it’s strongly suggested to choose one, at most two majors. As for hiring, it’s also easy to assume that if it’s hard enough to hire for just a single discipline, it must be at least twice as hard to hire someone skilled in multiple. I propose that it’s simpler than one might think - just evaluate candidates by their portfolio.

Software can have style

What makes a portfolio the de facto way of getting to know a candidate? In engineering, as well as in art, there are very few cases where isolated problems can be solved without considering the system as a whole. Take painting a view of Manhattan from the shores of North Brooklyn. The system, or painting, can be broken into smaller problems - how to paint the waves of the Hudson lapping against the pier, cargo ships and ferries, and One World Trade, but in solving these subproblems, the system (its audience, its style) must be considered. Similar to how a Cubist would demonstrate ‘the abandonment of a single viewpoint’ throughout a painting, a software engineer can make a stylistic choice to prioritize, say usability throughout an application. Why then, are many standard tech hiring practices evaluating on subproblems rather than systems? For example, Google’s interview involves an hour “coding” on a Google Doc, with expectations of writing syntactically correct code.

I think it’s an identity crisis issue. There’s lots of thoughts on how software engineering is an art, a science, a craft, but the gist of Vanderburg’s talk is that it’s its own young discipline that doesn’t need to mirror practices and processes found in other engineering disciplines, but should readily expand upon them when necessary. I’ll end with Vanderburg’s final quote on what he believes software engineering is -

“the science and art of designing and making, with economy and elegance, […] systems so that they can readily adapt to the situations to which they are subjected”.

Doesn’t sound like just a single discipline would cover all of that, does it?