You are not a software engineer (2011)

> If you were building a bridge or a skyscraper and you told me, before you began, that you knew exactly how it would look when it was finished – I would believe you. If you told me that you knew to some insane degree of accuracy how long it would take to get to ‘finished’ – I would believe you again. That’s how Engineers roll

Oh neat, maybe he can explain why the new Bay Bridge was practically a decade over schedule and billions over budget.

Or the Burj Khalifa was about 2 years overdue?

Or the California High Speed rail is projected to be twice the budget they thought, and they've barely broken ground on it?

So the idea that "Real Engineers" building bridges and railroads and skyscrapers get it right in plans and schedule is total bullshit. We've seen larger software projects, with more people working on them than these examples, hit their deadlines (Windows comes to mind -- except Vista).

And by the way, those "Engineering" disciplines have only been around for, what, hundreds, if not thousands of years. What they do for a living is mostly explored territory. Software, at least at a scale to be considered engineering at all, has been around for about 3-4 decades... maybe. And we're still hitting up against major unknowns all the time at every level of the practice, big and small.

edit: grammar

It's a slightly flowery (haha) way of putting it, but I agree whole-heartedly. I recently held a talk at a Python conference and I asked the question: degrees and job titles aside, are we scientists, engineers, artists or a combination of all of these. The overwhelming response was "all of the above".

My preferred term is "artisan". A software developer is applying techniques acquired primarily through experience, supplemented by training and outside knowledge. The artisan has a clear vision of the end result in high-level strokes, but the actual process and implementation is strongly dictated by experience and intuition.

Obviously there are different branches of software developer that have more characteristics of engineering, others of science, but I would hazard to guess that 80% of software development is essentially a guided artistic process.

I disagree for two reasons:

First, software engineers exist in a broader culture. The connotations of the various words in our respective languages are not in our control. "Engineer" and "gardener" have very different connotations. In a profession that sometimes struggles to gain respect, it would not behoove us to use a term that (wrongly in my opinion) is associated with lower social and professional status. If we could rewrite the English language and define "gardener" as a person with rare, hard-to-learn, and highly valuable skills, then perhaps we would do well to embrace the term "software gardener." But we can't.[1]

Second, software is engineering. This article seems to define engineering as Big Design Up Front. While that may describe part of what engineering can entail, it's not a complete or general description. If I had to describe engineering generally, I'd say it has to do with understanding and manipulating complex systems, analyzing and fulfilling requirements, distilling vague notions to concrete implementations, and building things that work. Software fits all of that.

[1] As I hinted above, I don't think it's fair, right, or accurate to denigrate actual gardeners as compared to software engineers. I'm stating the way most people perceive social status, not the way I'd like them to.

In August 1991 during the S&L recession and fresh out of Vocational School, I landed my first CAD jockey job drawing fabrication plans for a precast prestressed concrete manufacturer. The first task, after running Diazos and learning that neckties would become caught in the feed and where the reverse button was by feel as my face was pressed to the top of the machine and my air supply was rapidly constricting was drawing plans for a series of double tee members [TT]. It took a couple of weeks to generate the 100 odd variations and get them through the QA process, but then I moved on to other things.

But come October, they started to roll off the line...20+ kips of concrete a pop and then stacked three high. To this day, the sensation is fresh; "So that's what the fuck it really looks like."

The reason it's fresh is because it returns every time I am in the presence of some lines I put on paper manifested.

The picture of the bridge is not the bridge. The engineer, like the hacker, has better intuitions regarding the way in which the picture will correspond to its instantiation - but it is still no more than a [hopefully] informed intuition.[1]

[1] The idea that there is an Engineer rather than a thousand authors of a successful bridge tends to be a bit absurd in modern construction practice. Such heroics are still far more likely in software development.

I was hoping that a more substantial point was going to be made than this piece of fluff. Here is the substantial point.

If you're building a skyscraper or a bridge, an engineer has to sign off on the design. If the design subsequently proves to be defective, said engineer is personally liable. In many places, calling yourself an engineer when you are not licensed to sign off on designs and be liable in this way is against the law.

We can debate whether or not extending this principle to software development is a good idea. What we can't debate is that software development does not currently work this way. You, the software developer, are not an engineer. If you think a design is bad, you do not have both the legal authority and responsibility to stand up, declare it so, and force the design to be changed to something saner.

But saying you're not an engineer because software projects don't succeed like projects done by real engineers - that's both silly and wrong.

Ugh.

I wish we took the engineering metaphor more seriously. In particular, I'd like to see some real consequences for malpractice on the part of practitioners -- this would help us in our struggles with management to get projects done successfully.

I've seen so many cases, for instance, where people screw up simple things, such as generating primary keys, and keep making the same mistakes over and over again. This has got to stop.

As someone who lives in the mecca of the oil and gas industry and is thus around a lot of engineers--chemical engineers, civil engineers, mechanical engineers, and more--I can tell you that trying to argue too passionately about what constitutes an "engineer" is futile at this point. Engineers do everything from physically working on an oil rig to somewhat abstract economic analysis at a desk all day.

The only legitimate argument I can find regarding the use of the word "engineer" is that there are actual engineering licenses that can be obtained. But if we said that you had to have such a license to be called an engineer, that would screw up the naming conventions in a ton of industries.

The fact that the feedback loop of a software engineering process is much tighter and cheaper than that of civil engineering does not mean that it is not engineering - that's a fallacy.

Perhaps it's less applicable to civil engineers, because of the scale and safety requirements of their profession, but let's look at electrical engineering. An electrical engineer will build prototypes; they will build models; they will use computer simulations to predict how systems will behave; they will build testing and QA infrastructure. It's definitely harder to iterate—once you've built a million widgets, shifting circuits around is going to be expensive—but it's not qualitatively different to developing a software product.

As in any engineering discipline, software engineers must optimise for a system's required qualities. In some cases, reliability might not be that high up the list. In others—let's say medical systems, or those used in space travel—software engineers have rigorous systems in place to ensure quality, and in many cases substantial up-front planning and certification will be involved.

Ultimately this seems to say that software engineering is different from (specifically) civil engineering. I think that's broadly rather true – the nature of civil is such that generally there are stringent safety requirements, and indeed massive costs involved in making subsequent changes. The majority of software does not have the same requirements, and so it's no surprise that the process is somewhat different. And I agree that not all development is engineering, of course, but to dismiss the entire field is a bit of a shallow argument.

I disagree. When I code for my own amusement I might see myself as an artist but when I do professional work I definitely want to see myself as an engineer as well as a craftsman.

To me it feels as if we are just at a very early stage. It takes huge amounts of time to learn software engineering, putting aside mastering it and humans haven't been practicing for very long. So I'd guess that we're just clueless enough to not be able to feel like engineers yet. We learn most of our practical abilities from experience so thats an argument for craft, but once we get a better understanding of what we are actually doing, and formalize it, our job will probably be very engineery. There is just millions of problem domains and no formal education on the domain of writing software yet (no a CS degree is not it). And I think there is a class of applications that are already so well understood that they do get developed in an engineering fashion already.

I grow tired of the endless comparisons of software development with some other practice, profession, or physical process.

All analogies eventually break down if you take them too far. (If they didn't then you wouldn't be comparing something to something else; you'd be comparing something with itself.) But software development is so different from so many other practices and processes that most comparisons to gardening, building, finances, etc. don't provide much real value.

Its especially tiresome when it's claimed that "sofware isn't like that, it's like THIS". In the article, I find that neither gardening nor engineering is an especially enlightning analogy to software development.

I just checked my diploma, it says my title is 'Engineer' (studied computer science).

Engineering is a philosophy. First principles applied to real-world problems.

I'm not a Civil Engineer. So what? What does a Civil Engineer have in common with an Electrical Engineer or a Chemical Engineer? Very little day-to-day.

Or an Engineer on an oil rig? They'd laugh that Engineering means getting it right every time.

I can also tell you a Civil Engineer has very different problems if you're building a skyscraper in Asia, somewhere waterlogged, as opposed to somewhere geotechnically active. If you picked up your average skyscraper and dropped it in New Zealand, you'll have problems. Saying the techniques are the same is a gross generalisation.

I would like to see him “growing” a database or a compiler, perhaps a firmware for a car or the CAD software used by the architect to design a skyscraper.

This is basically wrong, because it compares designing software with constructing skyscrapers. But engineers don't construct skyscrapers, they design them. And designing software shares many, many similarities with designing skyscrapers.

I agree with the author though, that part of the problem is using engineering as a metaphor (at least, I agree up to the point where he just replaces it with his own, equally bad, metaphor). Software development is not like engineering, it is engineering, and the actual practice of it is as different from civil engineering, mechanical engineering, electrical engineering, chemical engineering or any other branch of engineering as those fields are from each other. None of those, by the way, bear even a passing resemblance to the description of 'engineering' contained in the post.

So yes, let's quit with the metaphors. Instead, let's talk about what engineers actually do, which is design: http://www.zerobanana.com/essays/reclaiming-software-enginee...

I admit that I like the cachet that goes with the title "Engineer".

I have no interest in worshiping the "real" engineers with their protocols and whatever. An engineer is qualified to build a bridge because they know how to build a bridge. Their professional ethics and protocols are secondary. And we certainly have ethics of our own, even if it isn't codified and we don't wear special rings.

Bleh... Can we just stop with the metaphors already? Maybe I'm not an engineer or a gardner or a scientist but maybe I am. I can be all of those things or none of them. I know how to make software of varying types and that's enough, how I apply those skills is a completely different thing. Maybe I'm a biologist using python to help see the migration patterns of fish better. Maybe I'm a web developer building highly scalable web systems in java. Maybe I'm writing drivers at a kernel level. It doesn't matter, programming is a skill set not a job definition. Engineers aren't just Engineers. They are Mechanical Engineers, Electrical Engineers, etc.. Scientists are just Scientists, they are Biologists, Chemists, and Computer Scientists. When we want programming/software development to have that same level of social standing we will use programming as a skill set not a job title.

Changing requirements and development landscape do not an analogy to a gardener make.

I do not 'grow' nor 'tend' code, trusting some unknown universal force to keep me on the right path.

I engineer buildings, bridges, roads, tunnels - all sorts. Sometimes they're very small and sometimes they're very large but they're all subject to the forces pushing and pulling on them - my job is to build them and keep them upright as well as I can subject to the laws and constraints of the environment.

I am not a gardener. I am an engineer building, modifying, and destroying complex structures daily in a controlled dance so as to keep their superstructure useful and safe.

Only to the naive eye could such complexity be reduced to such apparent simplicity.

To me, engineering is about solving problems, it's about taking systematic analytical approach to whatever problem arise. It is a state of mind, and that is why engineering now covers everything from software to biochemistry.

The part of this metaphor that I really like is how a garden is always changing. Unlike a bridge or a building, software doesn't stand in isolation; it's always relying on other software for something. These other pieces of the system are in constant churn, and your software must change with it. This is even disregarding other factors like changing customer demands. You have to continuously prune and maintain your garden, or the weeds (continuously changing software/hardware/services/etc. environments) will choke out your plants. Software is never "done".

I think the largest error in this analogy is that coding is closer to what the engineer does when designing something - not when building something. I guess construction in software is more like compilation.

Can a civil engineer say exactly how long it will take to design a bridge? No. Might putting more engineers on that project speed it up? Perhaps!

Coding is not so much constructing a program, but more creating detailed descriptions of every aspect of the system's operation for someone else (an interpreter, compiler etc.) to follow, and that is very similar to engineering design.

"Real" projects also know what they want in a year and don't expect the engineer to double the lanes on the bridge because the bridge went viral on social media and now needs to handle twice the traffic.

I'm not going to get into a who has bigger stones pissing contest, but lets just say the expectations and requirements for skyscapers are different than software.

You'd do just as well to call engineers "traffic gardners" who don't know how to make a bridge scale.

Engineering is about following best practices based on empirical data/knowledge as much as possible and "winging it" when faced with the unforeseen. Although "winging it" is a bit of a loose statement because generally unforeseen challenges are usually solved based on past experience and quite a bit of lateral thinking.

Therefor in my opinion software development "done properly" has more in common with engineering than gardening. :-)

My take on this. Not to say some people don't 'do' software engineering....but it is still nascent. http://jcooney.net/post/2012/02/27/What-Other-Engineering-Di...

Quite a few people really are software engineers, by qualification and by profession.

https://en.wikipedia.org/wiki/Software_engineer

That said, Chris has a good point that calling what you do engineering doesn't make you an engineer.

Dismissing all other organizations as worse at "gardening" than Google was a bit offensive.

And the lowest bidder for contracted work often sucks, or finds ways to bill more than the original bid. :)

I personally prefer the term programmer. What I do is program machines to do as I wish.

Gardener fits, but we design the plants in essence....

To me Programmer, developer, even software architect seems closer than gardener.

Op clearly doesn't understand software engineering and automation. Op may be a "software gardener" but some of us build proverbial skyscrapers.

A friend's mother once gave him a handwoven little sign that said "Engineer: faultless, accurate". As programmers we thought it was funny.

So what exactly is the take-away of this piece?

Software Engineering is an oxymoron.

This is why I became an attorney.

I'm a software hacker that gets paid an engineer's salary.

I use old tools (vim, terminals), like engineers use old tools (protractor, pencil), to make comparatively much larger artifacts (search products, management tools), like engineers (buildings, bridges).

You're not judiciously applying the metaphor. You've only rephrased what it means to be "self-taught"; it goes without saying that we don't allow unlicensed people to engineer things. It also goes without saying that no one lives or dies by a faulty HTTP request header.

I think this [silly] argument is nothing more than a special case of the argument over whether words have inherent meaning, or derive meaning from usage. I don't think 'software engineer' was ever meant to denote a new subtype of engineer. I think 'software engineer' is a compound word that means whatever it is we do. At work, whenever someone says 'get an engineer to look at that', absolutely nobody thinks that means to call one of the 'real' kinds of engineers on the phone. They know it means to get a software developer/programmer/code monkey/dev or whatever you want to call people who make software out of computer code.

I enjoyed the fresh perspective :-) Thanks for sharing