“Software Engineer”, “Computer Programmer” or “Developer” – these terms seem to be used interchangeably these days right? I suppose it is a step up from “the IT guy” but to consider these as the same role is rather missing the point. For many years I have discussed the merits and challenges in trying to differentiate the terms. In recruiting I insist that we are looking for “Software Engineers” which in my mind means something quite specific but given the applicants I see does not necessarily mean the same across the board. In fact the most vociferous response I had to that moniker was from engineers in other disciplines. “That’s not engineering!” they said, “There is no certification, no accountability and no rigorous standards you adhere to”.

The sad thing is – I think they are right. If we, as software engineers (or professional developers if you prefer) wish to be taken seriously then we have to listen to these criticisms. Engineering requires standards, it requires life long learning and it requires true accountability for actions. Think about a civil engineering project – nobody stands for a complete failure of a building or a bridge – but software issues are both expected and largely ignored. If we expect to be taken seriously then we need to hold ourselves to similar standards. It is a sad reflection on the state of the software industry that “Have you turned it off and back on again?” is globally understood as the remedy to most issues. Yes computer systems are complicated and yes the number of variables at play can seem daunting but does anyone truly believe that we are dealing with more complicated systems than the real world? At least computers do precisely what they were programmed to do – if we can’t explain what happened then we’re probably not very good at our job.

In my mind this is at least partly due to the considerable effort put into “lowering the barrier to entry” within the software world. The idea is an important one but it has led to a generation of software that can literally be put together by copying lines from popular Q&A sites and pasting into a development environment. If the code runs and seems to work the we’re done. Well no, not really. Is it tested? Is is easy to use? Does it conform to the design criteria or specifications? What happens if a user enters unexpected information or commands? What if the internet goes down or there is a failure in some subsystem? (A rhetorical question of course, as we will turn it off, back on and try again.)

There is no wonder that software gets a bad reputation when you look at what we expect people to put up with. User experience is touted as a glorious new concept – but how can we defend the creation of software that made no sense to the uninitiated? Do automotive manufacturers expect people to read a user manual before stepping into a new car? Can washing machine or dish-washer designers expect folk to attend a training event at a local store? The very idea that people are scared to try new software or upgrade what they have indicates the fragility of the ecosystem that we have all been complicit in creating.

Whether it was an intentional move to improve the recruitment pipeline or if it was implied in the requirements of a young software company there is a new push for “fast tracking” a software engineering career. At a recent meeting of the ScotlandIS software engineering leaders forum we discussed this very topic and around the table nearly 80% of the attendees thought we should be able to take a graduate level computer programmer and accelerate them to a senior software engineer in 18 months to 2 years. Can this really be an expectation that people have? My experience has shown that, even with a world class academic institution or phenomenal technical organisation behind you, it’s more likely to take 5 to 10 years to attain a high level of discipline in this field. Even if the “hard skills” can be learned in a compressed time-frame it will still take a large amount of practice to understand how these concepts apply in different situations.

The only source of knowledge is experience.
– Albert Einstein

Like it or loathe it there are various movements aiming to improve the stability and professionalism of our beloved software ecosystem. Test Driven Development may be the marmite of the software development world (you either use it religiously or are adamant that your team can’t spare the time) but it understands that quality is an issue for software creation. If we are to be taken seriously by engineering organisations, professional bodies and the populace at large then we need to think hard about these standards. Perhaps the British Computer Society are on to something with their push to get chartered status for software professionals? Such a move may be an additional hurdle to professional status but that does not have to mean it’s any harder to get started in the industry. If we can successfully champion the importance of separating learning and exploration from the creation of consumer and business products then perhaps we can actually raise the bar for software quality and earn our engineering status.

(Image from Code Monkey animation – visuals by idleambition, original song by Jonathan Coulton)