It was the coming of the steam engine that transformed the job of engineer into every schoolboy’s career aspiration. Until then the term had largely been used of military engineers, and those who employed their ingenuity to invent, fabricate or even plot.

But I have always been uncomfortable with the description of those who craft software as being ‘engineers’. That term has connotations of the mechanical that conflict with the more creative and inspirational aspects of software development. Maybe it is different for those who spend their life churning out printer drivers or SQL, but I suspect that few people do either from choice.

I am also struck by the observation that software engineering has been steaming away in exactly the opposite direction from most other engineering disciplines.

The rise of ergonomics, design to accommodate human strengths and weaknesses, has brought huge advances: gone are the days of bewildering arrays of meters, switches, and sundry devices. It was all too easy to misread and misuse such error-inducing controls. Although Apple has led the way in cleaning up the human interface exposed to users, it seems to have done the opposite for those actually writing software.

A couple of years ago I had cause to code my own tools to explore OS X’s Gatekeeper security sub-system, the results of which will appear in articles here. My quest for a suitable development platform was frustrating, because the only serious option was Apple’s Xcode, with its unrivalled access to the Cocoa programming layer.

I am no fan of Objective C, the original near-obligatory language in Xcode, which I have always found unfriendly and pernickety to the point of amplifying human error. Although enthused by Swift, it has only recently been added to Xcode, and I am not yet fluent in it.

Thankfully AppleScript has been enjoying something of a revival recently. Xcode’s recent AppleScriptObjC gives almost complete access to Cocoa and OS X from its more accessible and forgiving syntax, letting me write on myAction_(object) rather than Objective C’s opaque and punctuation-heavy (IBAction) myAction:(id) object, for example.

Xcode is in many respects a superb achievement, with as potent a human interface editor as you could wish, and component tools that are state of the art. But it is prone to utter and frustrating failure if a single check-box is incorrectly set.

Having created a clean, functional dialog, you then have to wire it up to ‘bindings’ in your source code. One wrong tick in a control’s settings, or a misunderstanding in a binding, and you are left stepping through a haystack of options, trying to spot the needle of your mistake.

It reminds me of a previous version of Xcode, which somehow defaulted to stripping out all the program code that you had just spent hours or days writing, so creating an application which could not run.

Although Apple has now set most of the major controls to useful defaults, I wonder how many developers could actually describe the effect and purpose of every single compiler and linker option, for instance. At times trying to get Xcode to do what I want has felt like driving a car with a separate steering wheel, throttle and brake for each of its wheels.

Contrast Apple’s recent changes to OS X Server, which has transformed from a fully-featured scalable product in Snow Leopard aimed at professional system administrators, to a facile tool for the casual administrator in small business, even the consumer market, in Mountain Lion and now Yosemite.

In doing so Server Admin’s large complex panes of settings have been supplanted by the simple Server.app, although not always as forgiving as it could be.

We can all now run our own servers, but should only engineers write software?

Updated from the original, which was first published in MacUser volume 28 issue 21, 2012.