One of the last posts was about engineering design. Software Engineers are not taught how to design and it is interesting to find so many other engineering disciplines who have devoted time to the process of design. This needs to be addressed in the software engineering education programs. But before we can talk about how to teach it, we must understand it and the good books on the subject are sparse. I am going to devote some posts to trying to organize my ideas and they will be influenced by the books I cited in the prior post, information I learned from Carnegie Mellon's Software Engineering Institute plus thoughts inspired by the architect Christopher Alexander.
Christopher Alexander, for those who do not already know him, is an architect who taught at Berkeley for many years and devoted a great deal of his career to the process of understanding how buildings are created. His PhD thesis was published as a book called Notes on the Synthesis of Form. This was a profound and abstract work that is more inspiring than informing. But it does lay out an argument that design goals create a network of connections between materials and constraints and leads to some form.
Later in Software Architecture in Practice by Bass et al they laid out a similar argument that the functional requirements in a software system do not give it the structure but instead the "qualities", what were formerly called non-functional requirements, that gave it shape. For after all, a functional system can be refactored in any number of ways without changing its functional properties. If the factoring, which is the structure of the system, does not change function, what is changed? This gets explored in their work and others.
As I see it, a key and fundamental difference between computer science and software engineering is that an engineer is generally hired to provide a service, in this case the creation of a software system that will satisfy some need. It is not done for the purpose of scientific exploration but to satisfy a client. Since economic concerns are directly brought forward as constraints, and since the human element plays a pivotal element in the use of any such work for hire, and since such work is more often than not a team effort and not the work of a single software engineer, the very nature of the task is qualitatively different. The ultimate driving force is to satisfy a client's need with economy.
Any problem solving requires a person to see what is not there. To use existing tools and processes requires an understanding of what is there and the creative possibilities of those available resources. Therefore there is always a kernel of creativity in any software engineering project. This can be as minimal as installing a commercial product or as difficult as a green field development for a completely novel and previously unsolved problem. Still the engineer must be able to both communicate with their client and have sufficient mastery of the technology to deliver on the vision that was discussed.
(to be continued)
