Coding or software engineering?
20th January 2022
There was a recent story on the BBC with the title "What can we do to get more women into coding?" The author was bemoaning the gender imbalance in the software industry, and she took it into her head "to find out how easy it would be for a woman in her 30s, to learn to code in Python". The rest of the article, interesting as it is, details how it wasn't as easy as she thought it should have been. But the real problem that that story illustrates is the idea that software development is nothing more than "coding".
"Coding" can be defined as writing a software program in a particular computer language – for instance, Python, or C, or Perl – in order to implement a desired function. And for many people, journalists included, knowing a chosen software language seems to be all that is required to do this. Certainly, if you want to write a software program, you need to know the syntax, rules and structure of the language you're using.
But coding is to software development as the hammer and nail are to carpentry. If all you can do is bang a nail into a plank of wood, you're not likely to earn the right to call yourself a carpenter. Learning a language – a foreign language or a computer language – is only the first step to actively using it. The context in which coding skills are used is best described as software engineering. This is a serious discipline which has been developed over decades. A full-blown software development needs a lot of work before a single line of code is written. The requirements of the project need to be detailed and the structure of the complete software suite needs to be fully analysed and documented, so that the function and interfaces of each software module can be understood. Only then should the module be coded; and if the preceding work has been carried out properly, the coding is the least intensive and complex part of the project – just like banging a nail into a piece of wood. Once the code has been written, the software suite must be rigorously tested to ensure that it actually works as it is intended to.
Back in 1983, this author wrote a pamphlet for the now-defunct campaigning group Electronics for Peace, reviewing the technical issues that were raised by the "expedited" development and deployment of the American ground launched cruise missile at Greenham Common. In looking at software reliability, it is worth repeating what I wrote then:
"Software reliability is different (from hardware reliability): there are no parts to wear out and once a program is correct it will remain correct for ever. The problem is to determine when the program is correct… The presence of errors in spite of testing reflects the complexity of a computer program. Not only must it be tested to ensure it performs as specified, but it must also be tested to ensure that it never performs outside specification – and given that a computer can assume a virtually infinite number of states during program execution, complete testing of any but the most trivial program is accepted to be impossible. In any case, no test can do more than prove that the software is consistent with its specification. In a complex system, the analysts who write the specification may themselves omit important functions or introduce unexpected interactions."
That last sentence is perhaps the most important of all; and systems analysis has virtually nothing to do with "coding". If you learn of a software project that's late, unreliable and riddled with bugs, you can be fairly sure that its developers, of whichever gender, aren't familiar with the discipline of software engineering. Perhaps, they just think of themselves as "coders".