Software engineering as art
In many ways, software bears more resemblance to complex social or organic systems than to hardware.
Ok, I’ve been reading a lot of articles lately and even I’d love to write about them all, the truth is that I don’t have too much time (in fact I must return to my personal project).
A couple months ago I found at developer.* an article written by Jack W. Reeves about the difference between software engineering and any other type of engineering and it’s kind of funny to see the position that even today is real:
In many ways, software bears more resemblance to complex social or organic systems than to hardware. All of this makes software design a difficult and error prone process. None of this is original thinking, but almost 30 years after the software engineering revolution began, software development is still seen as an undisciplined art compared to other engineering professions.
That’s exactly the part I like about software development, it’s an art. As a developer (software designer, software architect, software engineer, programmer) we just don’t face the engineering issues related with building, in this case, software, but we also have to think creative solutions, sometimes we have to redrawn everything from zero, and sometimes we paint something really beautiful.
What about the Code as Design part? well, according to Reeves building a software is really cheap - it’s so cheap, that final cost is almost none - but the expensive stage is the design part: we must design the solution, sometimes even redesign it and these steps include testing and debugging
… if we consider source code as design, we see that software designers actually do a considerable amount of validating and refining their designs. Software designers do not call it engineering, however, we call it testing and debugging …
One of the main reasons that make software design an expensive task is that all different aspects interrelate; a bad choice at a higher level will impact a lower layer and viceversa:
There is no hierarchy of importance among the different aspects of a software design. An incorrect design at the lowest module level can be as fatal as a mistake at the highest level.
Finally we reached the part where we found out that coding is designing. It doesn’t matter if we use a CASE tool or a diagram generator or even an spreadsheet (which is very useful to work and help us to draw the ideas and to record the process we’ve followed to create the software), what’s more important beyond all of these auxiliary documents is the code. With code we represent the design and prepare the foundations to create the software (this part is done by compilers, linkers, parsers, that’s why it’s cheap to build software), using a programming language we can express high level information about design components.
We must keep in mind, however, that these tools and notations are not a software design. Eventually, we have to create the real software design, and it will be in some programming language. Therefore, we should not be afraid to code our designs as we derive them. We simply must be willing to refine them as necessary.
I really recommend this lecture written by Jack W. Reeves 11 years ago and true even today, it contains the original letter What is Software Design, a second letter What is Software Design: 13 Years Later and the Letter to the Editor