originally posted on one of my several now defunct blogs, called On Engineering on 7th August 2012
Software seems to be getting all the glory these days, with the notable exception of the Curiosity landing - but any system that uses a a rocket crane to gently place a one tonne nuclear rover into a crater on Mars is astounding. Aside from the MSL, though, it’s all Facebook this and Google that - even Microsoft, the uncoolest of them all collects kilometres of headlines. I get the impression that engineers like me, working on “things” like metals, coatings, fluids, remain unlauded. In modern parlance, I work on “dumb*” things. They are non-trivial things, of course, otherwise I wouldn’t be engineering them, the products I work on also have many millions of users and the company I work for even makes a profit - but it’s not software.
The world of software deserves its acclaim. The engineering that I do could hardly be imagined without IT. Spreadsheets and presentation tools, web browsers, emails, data analysis software all across the spectrum to text messages are an integral part of my working life. In one sense, then, software is “merely” a tool that enables me to add value to things. Equally, I am aware of the tools that I use when I’m not in the office: music sequencers, smartphones, GPS systems - and blogging apps, of course.
All of this software resides in hardware, but in many cases the physical is largely transparent. Software defines the utility of the hardware.
So software is one of modern life’s key enablers. It can be stunningly complex and is in a perpetual state of development (unless the company goes bust or is bought out for its team). The question is, though: is software engineered, or does it somehow “happen”?
Put another way: if I were to dust off my Basic or my Turbo Pascal and hop over to a software company, would I recognise what I would do there as engineering?
The title Software Engineer certainly exists. It can be found in the job pages of Facebook and Yammer. There are university courses offered in Software Engineering the world over. There is a Software Engineering Institute at Carnegie Mellon, and the Fraunhofer Institute has its own Experimental Software Engineering group.
Yet despite all of this apparent validation, the title still seems diffuse and interchangeable. Some companies avoid the title Engineer altogether, using by preference the word “Developer”, which seems currently to have the highest cachet, whether the practitioner is Junior, Senior, Expert or Chief Expert. A developer friend tells me that where he works, the title “engineer” is not used at all, as it smacks of robust inflexibility grounded by paperwork, whereas developers are by nature free to react quickly and autonomously to the ever-changing requirements and bug discoveries that define software.
I see what he means (and take slight, but acknowledging umbrage at that assessment of engineering). But others use the title “Engineer” as a standard moniker - including Google, of all places. So how do they use it?
James Whittaker (now back at Microsoft) in his highly engaging book “How Google Tests Software” describes many of the development tools used by Google during software development. They seem to be parallels of my own tools. He talks about specifications, about a kind of FMEA (risk derived from what Google calls ACCs - Attribute / Component / Capability factors), about test and validation, about breaking things to find their weak points and subsequent focus on fixing those areas.
A Google Software Engineer (also described in the book as a “feature developer”) is responsible for delivering tested, bug-free code to a particular project. Software Engineers in Test are geared up to write code and test-frameworks to find bugs in the product, and Test Engineers work specifically on ways to break the total product in clever ways.
It all sounds quite similar to my world. Instead of code, I write drawings and specifications. I organise testing and validation, I have to deal with change. Our manufacturing engineers ensure that product can be made and our quality engineers ensure that product is measured and released for sale. However, whilst specifications, documentation and requirements are all present and largely correct at Google, they come across as being secondary to the ultimate goal of shipping bug-free code.
This is of course totally true. They are secondary (I shudder when I hear Quality Managers refer to what they do as “value add.” It’s cost-added for value saved.) However there is a different emphasis on rigour between software and hardware that may be reflected in the real titles of hardware engineers but software developers.
One of the directors quoted in How Google Tests Software explicitly states “I suppose there is a fairytale world where every line of code is preceded by a test which is preceded by a specification… But in the innovative and fast-paced world that I live in, you get what you get… Demanding a spec won’t get you one… I can whine or I can add value.” Equally apposite: “Test plans are the first testing document to be created and the first one to die of neglect.”
These statements reflect the same pressures that I experience as a mechanical engineer. We also have timing pressures to deal with, and spec writing is also a necessary evil. But the attitude seems different. I simply could not imagine such a statement coming from a GM or Daimler director, let alone from that great automotive bureaucracy, Volkswagen.
Documents and specifications aside, subtly but tellingly, in a series of interviews with Google Test Directors at the end of How Google Tests Software, each director refers automatically to developers and only occasionally use the word “engineer” as a secondary term.
So perhaps engineering is a nice-to-have concept in the world of software, a little bolted on. On the other hand, we engineers may be too static and outmoded for the modern and fast-paced world of gold-medal software firms like Google. Perhaps our production models that involve factories, process engineers and ISO / TS audits are too rigid to take the liberties that the softies can take and get away with them as often as they do.
But as we have seen, the title Software Engineer is very much in existence. Maybe we need to take a step back from software’s cutting edge to where software takes a secondary seat to the hardware. Car or aircraft entertainment systems, or production process control systems would be good examples, as would be the medical equipment industry.
The clearest answer I have found so far to the question “Are Software Engineers Engineers?” lies in a job description for a medical equipment manufacturer. Here’s what this software engineer is supposed to manage:
Development of software Verification…of Quality Management and Regulatory Affairs Collaboration for the development of software requirements Development of the software architecture Implementation and integration, supervision of external resources Support of product maintenance Production and customer care
This collection of responsibilities sounds more like what I have to manage on a daily basis. This software engineer must juggle the code and its application, must (this being the medical industry) monitor specs and regulations carefully and must ensure that production is secured, whilst also designing in a certain ease of use for the end user (I wonder if they say “end user” or “patient”? I think it makes a difference…).
It doesn’t sound as sexy as a startup’s freedom or a Google’s heavyweight fleetness of foot, and it doesn’t reflect much of the pioneering spirit of a Brunel or an Edison; but it’s engineering as I know it.
Perhaps the difference between the software developer and the hardware engineer really is as simple as the maturity of the market and of the company. Just as terrible auto accidents in the 1970s and 80s resulted in ever-increasing regulation, so potential privacy disasters at Facebook and Google is landing them with audits and governmental control.
Perhaps the Zuckerbergs and Larry Pages of today are the Rolls and Fords of yesteryear, and their companies are destined to become as bureaucratic as their successful forebears. The attraction of startups is that they are small and start under the radar of heavy regulation. To achieve the scale and success of Microsoft or Apple, of BMW or General Electric, they too must generate a strong, supporting skeleton. The trick and the challenge is not to let that become a fossil.
So in the end, what’s my answer? Is Software Engineering Engineering? Yes, it can be. There are sufficient differences that both worlds can learn from each other, even if they cannot often transfer people (I see myself more easily transferring to the nuclear industry than to Google) but the disciplines and tools involved have their parallels. In the balance, I feel that my world could learn more from software than vice-versa, especially in terms of sleekness and agility. What could they learn from us?
Apart from great paperwork, I mean…
I’d love to hear your thoughts on this theme, too. Are you a Software Engineer yourself? Or are you somewhere in between (in avionics, say, or electronic gadgetry? Fire away!
*dumb: software is deemed smart, but it, too, can be reduced to equations and lots of “if…else” statements. Not as dumb as they sound, my components react to certain conditions in particular ways, and with more subtlety than many programmes do.
