Embedded Curmudgeon Column
|
There is long-standing debate as to whether software is an engineering discipline or an art form. Engineers insist that rules, process and rigour should apply to the production of software, whereas the artists insist that they should not be bound by rigid (or any) rules. Rules, they say, may restrict their creative processes. A dilemma!
Since the positions are based on viewpoint and beliefs, the discussion rapidly becomes “religious” and entrenched: arguments are made more to score points than explore the possibilities of any compromise.
It is time the subject was viewed from a fresh standpoint, and in exploring this question, I discussed the problem with three artists. I talked to a graphics designer, a film producer and read a book by a former dancer, all bona fide artists. In the end I came away surprised or even, in fact, a bit shocked.
The graphics designer is very arty. However, he explained that at university he was taught lots of methods, rules, and other skills all of which required effort, and above all discipline, to master. Also a lot of these techniques seemed to be counter-intuitive. The techniques he learned go towards explaining why a professionally produced magazine, such as the one you are reading, feels so much better than the parish newsletter. Afterwards I remembered similar comments coming from the editor of a club magazine. A professional publisher took him through their processes using one of the club’s magazines. The changes made, though apparently minor, made a huge difference to the readability and feel of the magazine. Sticking to the rules of layout, fonts, colours etc produces a result that does its job better but still has creativity.
Likewise, the film producer explained that he had to learn the science of light, the science of movement, depth of field and many other techniques and methods. It is this, rather than the equipment used, that explains why a professional film looks so very different to 95% of the stuff on You Tube. The art comes from using the toolbox of methods and techniques in a disciplined way. But, he said, filming was the shortest part of the process! First he needed a script and then he storyboarded the whole film: EVERY shot was scripted and storyboarded. (Translating this to software we are looking at a requirements specification and a detailed design.) Why? Time and costs. You can’t afford to do any film, other than a short hobby film, without the film world’s equivalent of a full set of requirements and a full and complete design. Hobby film makers think that film making is all about the filming, just as hobby programmers think that software is all about writing code.
In both cases the creative people said you have to work hard and learn the skills and techniques with a lot of discipline. Being self-taught or not applying the discipline of methods and protocols was far too expensive unless doing it as a hobby. Also a full understanding of the rules and techniques was needed before you could break the rules: with that knowledge you knew what rules you were breaking and why.
My third artist is Marnie L Hutchinson, who was a dancer and performer for many years before moving into software testing. The introduction to her book, Software Testing Fundamentals points out that dancers need to master many techniques, to endlessly practice and have a very high discipline. Before any performance there are warm up routines and, other than for artistic free form, there are walkthroughs and rehearsals. For many things in dance, for example for lifts and pirouettes, you must use the right techniques or you end up damaging yourself and others. She then uses this background as the basis for discussing the disciplines needed for software testing.
So it seems all successful artists, even hobby artists, need training, rigour, discipline, methods and rules. When you get to the top and can work to all the rules, almost without thinking, then you can create art. Yes, there are a few exceptions who break the mould, but they are very few and far between.
Look at the number of musicians there are in the world, both professional and hobby types. Yes, there are a few rock stars (but many crashed and burned before getting even close to the top). However the people who earn a good living at music are the session musicians, who play on the CD’s and downloads, and provide the backing band on TV shows and tours. They are technically good musicians, are disciplined and can quickly pick up and play to the house style. They are in great demand and earn a good living for many years. How many of the “artists” on Britain’s got X Talent Factor are ever heard of again? Even the winners? Possessing a bit of flair and aptitude but without discipline and techniques does not make you an artist, let alone a software engineer.
Finally, take a look at architects. They have a huge number of rules to work to. They have to obey the laws of physics, engineering, national and local planning laws, follow the guidelines of health and safety and cope with the regulations for the specific type of building that they area creating, for example a bus station or an office. And all that is before they get to the customers’ requirements! Yet you only have to look at any city skyline to see architectural “art” shining though. (Cue discussions with Prince Charles on art and architecture?)
In structural engineering, two engineers equally well trained, may come up with very different answers. Foster’s Millau bridge is art, while many other bridges are merely a solution.
So, if we accept that software is an art then, by an analogy with other arts, the art can only be successful if it builds on methods, techniques, training, and above all the discipline of doing things correctly.
No software person should be arguing over coding style. Like a session musician they should just pick up and use whatever the house style is. Their art should be in the design of the software, in creating algorithms and safe, readable and maintainable software: the greatest skill in software is creating software that works reliably and that can be maintained.
According to Michael Barr, “The average embedded software project devotes 50% of the schedule to debugging the code. It's stunning to realize that half of the project's time is wasted fixing mistakes.” So by properly engineering the code to start with, so you don’t have to devote at least half of your time to flattening bugs, perhaps then you will have more time for the art?
The Art in Embedded Systems comes though Engineering Discipline.
Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE FRGS FRSA is a Technical Specialist and can be reached at This Contact
Copyright Chris A Hills 2003 -2013
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988