Today I had a conversation with an aeronautical engineer on the position of the system engineer in different technology sectors.
The aeronautic industry is famous for having solutions using multi-discipline effort, requiring various groups to work in coordination. Each group works with different methodologies and speaks different languages. There is no real way of each group knowing the methodologies and be completely fluent in all technical languages, so some kind of mediator is required in order to help the communication.
The task of helping the groups communicate and understand the major ideas presented by each group is the task of the system engineer. He is also responsible on resolving conflicts and conveying the requirements in a meaningful form to each of the groups.
Since the system engineer's perspective is very wide, he can mediate between groups and allocate the effort to fit the requirements. The system engineer serves as an aid to the project manager for allocating resources.
Another use of the wide perspective is the knowledge of knowing what is important and using that knowledge to ask the relevant questions to each group. Jeff Atwood refers to this in a film the towering inferno. In his post, the expert is the one who knows what is important to ask.
The post represents the major difference between software development and aeronautic solutions. In software there is little difference in the languages, at least at face value. There is little difference in methodologies and theoretically everyone knows what's important.
This view is limited as it does not cover complex solutions requiring many components. In such scenarios, the programmer of each component is unaware of other groups, sometimes using different methodologies, like comparing an oracle DBA and .NET programmer. Thus the role of a system engineer is required but less understood and much less acknowledged.
Looking at the different sectors it becomes clearer why the role of the system engineer treated very differently. Unfortunately, most programmers don't seem to grasp the difference between knowing the intricate details of software and understanding the broad view of a system. This is the difficult task of teaching why software design requires a system engineer.
Is software engineering so different from other branches? There are many analogies for software development, like building a structure or gardening, each one giving a different perspective. One perspective I find lacking from these analogies is the development as a critical path, when development is the act of producing a result from a set of requirements.
Comparing to electronics engineering is very interesting as there is a lot of similitude: (this list is very rough on purpose)
1. Electronic devices are built to specifications
2. The solution must be readily available with existing components, or
3. New components need to be build
4. Pilot products are produced to test the design
5. The end product is built from the design
How this compares to software development?
First, there is no real production phase for software, because the copying of the software is not error prone. Of course there is the deployment phase, but this is comparable to electronic equipment setup.
Second, the development process in software is much more central and has a higher percentage of staff involved. The reason of being the additional phases required for electronics production.
Third, the Quality Control in electronics is relevant to the production phase for assuring that the produced units are within the error margin.
What can be learnt?
Software has the same basics, of creating software to solve a problem, under specific constraints. Unfortunately, since there is no production, the software goes to the user directly from the development phase.
There is also a difference in the rules and tolerances of electronics vs. software. Electronics have rules that help guarantee the end result and the margin of error based on previous experience and limited by safety rules and regulations. The same does not apply to software because software is not relevant to electricity or energy handling so the safety rules do not apply directly.
This short comparison gives a small clue why comparing the rules of software to production rules are misleading and software should be compared with other methodologies, but with a grain of salt.
Rules are made to be broken, this is a quote I live by and use extensively for software design. The quote came to my mind reading the post by Jeff Atwood on Programming rules and the following post. The idea of programming rules, the vast majority of programmers that are clueless of programming ideas and more even of systems, makes me understand the difficult position of a system engineer.
Most programmers see programming as a work, something for making money, so one can so something else with the money. Only 20 percent are move involved, see themselves as craftsmen, wanting to improve. Of those 20 percent, only a few read book, look for information and methods for growing. These programmers will read about programming rules, about guidelines and methodologies and will try to embrace them.
This is the place where the system engineer can make a difference. The guidelines and rules provide a path for generalizing the problems or solutions and put them in a reference frame. The reference frame of software design can be suitable, but it can also guide the poor programmer into really bad concepts that are taken from a completely different world. Hence the system engineer should be the one providing the guidance, understanding the frameset of the guidelines, helping implementing and helping in the selection process. There are so many rules and guidelines, so the selection process is critical.
Concept integrity is a corner stone of software design. It is a means for achieving a uniform and aesthetically pleasing solution, providing consistent behavior from different perspectives. The relevant perspectives depend on the user, maintainer, programmer or other people coming in contact with the system. Each perspective requires attention at different levels and manages different complexity of information. This is why the concept integrity meaning is different at each level and why the idea of concept needs clarification in the correct context.
What is a concept?
Extract from wikipedia:
"Concepts are expected to be useful in dealing with reality. A concept is basically the main idea. Generally speaking, concepts are taken (a) to be acquired dispositions to recognize perceived objects as being of a certain ontological kind, and at the same time (b) to understand what this kind or that kind of object is like, and consequently (c) to perceive a number of perceived particulars as being the same in kind and to discriminate between them and other sensible particulars that are different in kind."
In plain words:
Use the same ideas in the same way, to perform same actions in similar methods
Here are two incorrect fictional examples:
API:
File open: fopen (handle *, filename, properties)
File open for readonly: handle = filereadonlyopen(filename)
UI:
Opening a file: use the file -> open menu option
Opening a template: incorrect use - go to options and list the templates.
As seen, both examples display similar actions in very different ways, alienating each user. For the programmer, learning how to use each function and knowing they are different in bothering. This can be seen in the reactions to the windows API changes. For the user, finding the templates can be frustrating because the logic need remembering and not finding the action in the assumed place is very annoying. A good sample is the reaction to the ribbon in office 2007.
