I remember years ago, after I had been working a couple of years, having a long argument with someone who disagreed with us calling what we did software engineering. I have recently been reminded of this by Joe Wright @joe_jag who has been asking whether engineering is a bad metaphor.
He gave a lightning talk at Lean Agile Glasgow tonight on the topic. His argument is that the software engineering which came out of the initial “software engineering conference” organised by NATO in 1968 took as its inspiration structural engineering, and actually misunderstood a lot of the reasons anyway. For example we saw mathematical models and thought they were used to do the design, whereas they are actually for cost reduction since they’re cheaper and faster to build and iterate than prototypes.
Anyway, he argued engineering was a bad metaphor, (and offered cultivation as a better metaphor).
I think this misses what engineering is. We look at a production line and think that’s engineering, but it isn’t. It’s production. Our equivalent is compiling, or maybe pressing the DVDs with the final product (those of you who remember products that actually came on physical DVDs). The engineering part was coming up with the design that the production line is building, and optimising the production line, and so on.
So what is engineering? Fundamentally to me it’s the management of compromise. It’s about building/developing/producing as good a solution as you can within a certain set of constraints.
These constraints can be time, resource, market window, physics, human behaviour, existing building blocks/product, target cost, efficiency, load, …
Good will vary depending on the product as well. It will be a mixture of feature set, price, robustness, scalability, manufacturability, flexibility, customisability, cost to manufacture, throughput, efficiency, …
Every project has a particular set of constraints to work within, and a target deliverable. In the case of BloodhoundSSC, the constraints are mainly physics, and the target output is a car than can travel at 1000mph on land twice through a measured mile within an hour. In the case of a can of Irn Bru, the constraints include the price the consumer will pay, how thin you can make the can while still maintaining structural integrity (save a fraction of a penny on every can, and with millions of cans it adds up), how many cans of the drink you can produce in a given time, how easy it is to transport to the shops to be sold. You get the idea.
So, given that definition, are we engineers? I would say absolutely Yes. Our constraints are development time and resource, how well the developers can coordinate and cooperate, how week we can understand our customers… or experiment to understand our customers, market windows, hardware limitations such as resources, timing/speed, operating system(s), skills of our developers, available libraries, compilers, debuggers, test frameworks. Our target output will vary from project to project, including what good means – the quality required for a Web page is rather different from the quality required for a nuclear reactor controller. Fundamentally the target output will be defined by Bob Marshall’s Antimatter Principle “attend to folks’ needs.”
So is engineering a good metaphor for what we do? Absolutely Yes! That’s not to say other metaphors can’t also be useful – I do like Joe’s cultivation metaphor, but let’s not throw the baby out with the bathwater.