This article discusses the comparison between software engineering and other engineering disciplines, taking as examples the aerospace, construction and automotive industries. We compare the processes used and the roles played by different team members in the different industries.
Software engineering is often thought of differently to other engineering disciplines. The product of civil or mechanical engineering is something visible and tangible, a bridge or a car. We talk of engineers "building" these things. The products of software engineering are not often thought of as having been "built". In contrast to this, software is usually described as having been "written". However, with some consideration we can see that the process of creating a piece of software is, or at least can and should be, similar in many ways to building a physical structure. In this article we consider the engineering processes used in designing and producing an aeroplane, a building or a car, and compare and contrast them with those used in software engineering.
A dictionary[1] definition of engineering is given as: "The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems." This definition could equally well apply to the production of any of the types of things mentioned above. It doesn't matter what tools we use to build them, or whether or not we can reach out and touch the finished product.
To take an example of a comparison between "real" and "virtual" construction, think about building an aeroplane. Building a passenger airliner is somewhat different to making a paper aeroplane. You can make a paper plane by yourself. It doesn't take very long. If it goes wrong you can unfold the paper and start again (or perhaps even throw it away and begin again with a fresh piece of paper). If after a few flights it gets a bit damaged, you are unlikely to care too much. You cannot build an airliner by yourself, it requires a large team of people with different skills, and is just too much work for one person even if they did happen to have all of the skills required. This team needs to be managed carefully to ensure that you end up with what you want. This means careful planning is needed. Initial thought and careful design is also necessary because the amount of time, effort and money required to build an aeroplane means that you can't just take it apart (or throw it away) if the construction doesn't work out quite right. Finally, airliners are designed to carry many tens of thousands of human passengers large distances through the air. If they break down or are damaged then this could lead to a large loss of life. This imparts a lot of responsibility to the engineers to build to a high standard.
These two cases represent the two extremes of the aeronautical engineering spectrum. We can think about corresponding cases in a software engineering environment. Making a paper aeroplane might equate to quickly writing a piece of software for your own use or amusement, perhaps to carry out a one off task. It's not worth spending the time designing a reliable structure to deal with inconsistent input, or generalising routines for future use if no further work is going to be done on the project and the task is not that important. The other extreme might be working with a large team of developers, producing a complicated system over the course of a number of months or years. To coordinate the development team detailed plans need to be made. To ensure that development effort is not wasted, the system must be designed with sufficient thought and rigour to ensure that it can be developed and expanded to include extra functionality that may (and in practice, always will) be demanded. As with an aeroplane, software's application can be in a situation where human life is at stake, for instance in transport control systems or medical equipment. The same care needs to be taken in developing such a piece of software as would be shown in building the airliner.
One thing that the design of houses has in common with that of software is that each unit is often individual. The use of design patterns was Christopher Alexander's[2] solution to capturing and reusing knowledge gained from many previous architectural designs to use in new projects. This technique is becoming increasingly popular amongst software developers, especially since the publication of the Design Patterns book[3]. Software, especially that designed for in-house corporate use, is often bespoke and tailored specifically for a particular application. In the design of a mass produced item like a car, as we will discuss later, many prototypes will be constructed, tested and discarded before coming up with the final version. Large pieces of software tend to be developed incrementally. It is too expensive to develop prototype systems, test them and throw them away repeatedly. A basic structure is put into place and extra functionality is added gradually over time. Here, instead of taking knowledge gained from many centuries of house design and applying it to software, we consider what would happen if we took the development process typically used in dot-com style technology companies, and applied it to construction.
Think about someone building a house. First of all they want to construct something quickly to shelter them from the elements. To start with they aren't concerned with fixtures and fittings, just the rudimentary structure to provide a roof over their head at night. They are likely to dive straight into the building work, with little or no planning, because they want to get to a result as quickly as possible.
It is common that the first incarnation of the product will be put into use as soon as it can be. Think of the man building a house, imagine it's raining. As soon as there are walls and a roof he will move in. He won't build a house, see how strong strong it is, solicit the critical opinions of his friends and neighbours, knock it down and start again, only moving in when he has finally got it right after three or four attempts. The first house may not have all of the things that he might want, but it will keep him dry and he can improve other aspects after he has moved in.
The first house, put together quickly, is built from easily workable timber. It isn't particularly strong, but it gives the shape of the house and provides some shelter. After a while the weather will worsen. In preparation for this a more resilient structure needs to be put in place. As the house is already being lived in, care must be taken to ensure that while the building work is going on this does not interfere with people being able to go in and out of the house, disturb the provision of water, gas or electricity, or prevent the delivering of mail etc. It may be disturbing to other people living in the same street, the postman and other people coming to call at the house if the building work is obvious, and so it may be best to build stone walls on the inside of the existing ones and then to remove the timber when the stonework is completed. Doing the building work on the inside also allows the builders to stay dry if it rains.
As gradual improvements are being made to the house, the presence of the builders is not too much of a problem. They keep themselves pretty much to themselves. As long as things like the doors and the windows (which people are now used to using) stay in the same place, everything will be ok. However, changing the way that people interact with the house will cause problems. Bricking up the front door and putting a new main entrance at the back of the house will confuse the postman, maybe leading to no letters being delivered. Also, doing anything like changing the locks without plenty of prior warning will cause lots of trouble as people with old keys will not be able to get into the house.
Consider what happens after a couple of years. The house is now the home of an expanding family. Soon there won't be enough room for everyone. One possibility is to build an extension onto the back of the house. It's preferable to build the extension on the back rather than the front as there's likely to be more space there and you won't be building out in the public road and disturbing everyone. Also if you build onto the front, there will again be problems with access to the front door. There are two problems which may be encountered with this approach. The first probably isn't too much of an inconvenience with a house, but may prove more so in software terms.
If the postman comes to deliver a parcel, and rings the doorbell, he may have to wait a relatively long time for the right person to come to the door if they are in their room at the back of the house. This would be made worse if instead of building the extension directly onto the house a separate structure had been built at the bottom of the garden. Imagine the following scenario: the doorbell rings. The father opens the door to find one of his daughter's friends asking if his daughter is at home. The father goes to look around the house. Not finding her he then has to go down to the bottom of the garden to see if she is there before being able to give an answer to the waiting friend.
In software terms, the same sorts of problems appear when we try to scale up a system. Increasing the amount of storage space may mean writing data onto disk rather than keeping it all in memory, and having to look around for where the data is stored before being able to return it can hit the performance of the system, causing delays for clients.
The other problem is simply that you can only extend your house so far before you run out of land. In this case the only option is to move somewhere else.
At some point, the limits of the physical resources of your hardware will be reached. For example there is no more RAM or disk space to store data. The only solution here is to move to a different set of hardware.
There are many problems associated with moving house. One is that if you don't remember to tell everyone, they will still send you letters at your old address. While you are likely to remember to tell your best friends where you are moving too, you may forget to inform, say a wine club that you joined to take advantage of a special offer one Christmas. You might miss a fantastic offer on 24 bottles of Beaujolais. The new occupants of your old house may have to put up with an increasingly large pile of post which is not for them until one day they get fed up and throw it all away. If you are lucky, and you remembered to leave a forwarding address, they might post some of the letters on to you (perhaps the ones they think look important). Alternatively you could pay the post office to redirect your post to your new address. Either way the letters will take longer to reach you, and are not 100 percent guaranteed to arrive.
At this point we are probably starting to draw out this analogy too far, but it is interesting to see how the problems that we may experience in one domain may map to another.
Anything but the most trivial engineering task will be undertaken by a team of people with different skills. Let's consider the work done by different people on these teams, and how their roles relate to each other and to the project as a whole. Let's consider three different industries: construction, automotive and software.
The construction industry is concerned with buildings and other large physical structures like bridges. These are not mass produced, but generally designed and built in a bespoke manner for each separate job
The client is someone, or an organisation who needs a building, say an office block, a hospital or a house. They provide the need for the project, the requirements, and the funding.
The architect comes up with a high level design for the building. They decide on how many floors there need to be, how many rooms, doors, windows etc, and what these should be made of.
The engineers, of which there are several different types with different specialisations, make more detailed specifications to try and realise the architect's design. Structural engineers calculate how strong things need to be in order that the building will stand up. Services engineers work on designs for electrical systems, plumbing etc.
The foreman manages the building site, where construction actually takes place. They manage people and resources to try and get the building built according to the plans as quickly and efficiently as possible, while maintaining quality.
Craftsmen and labourers do the actual construction.
The automotive industry is concerned with building cars and trucks. These are normally mass produced for mass market sale.
The client may be seen as the customer who buys a car, but it may be that more of the push for producing new models comes from retailers and marketing departments of car companies trying to tempt customers to buy new cars, perhaps more often than they actually need to.
The designer comes up with the general shape of the car, the way that the parts fit together and the styling of the interior and exterior.
A large number of different types of engineers will then work on the more detailed design of individual components. Different engineers work on engines, gearboxes, electrical systems. Test engineers assess components and systems. Manufacturing engineers will design the process by which the end product will be produced on the production line.
The production line manager looks after a section of the manufacturing process on the production line.
Technicians weld and bolt different components together.
The client can be one of many different people, either an end-user, a company, another department within the same company etc, but there must be someone who needs the piece of software to be written.
The architect designs the structure of the system as a whole. They design within which components computation will be done, and what the dataflows between these computational components will be.
A lead developer will manage the technical work of one development team, helping to integrate the individual components. For a smaller project this role may be taken by the architect.
The developers write components of the software to meet a specification. They may be specialists in certain programming languages or technologies.
Comparing these different teams, it can be seen that the high level design of both a building and a software system is done by someone who we call an architect. They are responsible for conceiving the general structure of whatever is being designed, designing initially with broad brush strokes. Their work will show the most creativity of anyone working on the project. People working on more detailed aspects will later check back with the architect for guidance in making sure that their work fits within the overall scheme. This is very similar to the designer's role in the automotive design team.
At the other end of the scale, on a building site there are a number of specialist contractors, brick-layers, carpenters etc, who use their skills to construct parts of the structure based upon a specification given to them. A brick-layer may decide how to fit bricks around a window, and a carpenter may decide on what types of joints to use, but they cannot suddenly decide that a different material should be used altogether, or that things should be built in a different place. On the car production line, the technicians fulfil a similar role.
On a software team, the person working at the lowest level is a junior developer. Someone may have skills in a particular programming language, or a particular web technology which they can use to implement a specification given to them. Different developers have different skills, and a good team will be made up by balancing different numbers of people with different skills as the project requires. However, if we consider the work that these people do in comparison with the labourers and technicians considered previously, there seems to be something of a disparity. Let us try and align the roles of the people in the different teams.
| Construction | Automotive | Software |
| Client | Client | Client |
| Architect | Designer | Architect |
| Engineers | Engineers | |
| Foreman | Production manager | Lead developer |
| Craftsman | Technician | Developer |
The first thing that we notice from this table is that there seems to be no-one in the software design process working at the same level as the engineers in the other two situations. This could be a cause for concern, as it is the engineers who do the detailed work which ensures that, for instance, a building will be strong enough not to fall down, or that a car engine will be sufficiently powerful to propel the car at an appropriate speed. Who is responsible for ensuring that a software system fulfils comparable non-functional requirements of reliabilty and performance?
Considering the work that is being done at the bottom of the table, the developer seems to have a lot more freedom to be creative in their work than the craftsman or technician. Could this be a bad thing? If the people constructing software are creating their own interpretation of the specification and making design decisions, will this lead to a high quality product?
However, one thing points to the fact that it may not be appropriate to align a developer with a technician. Someone with a university degree in computer science may enter a company as a developer, the lowest rank in our table. However, someone with a similar degree in civil engineering would not expect to take a job as a brick layer or a labourer. They would expect to start working at the engineer level.
Perhaps then we ought to align developers (who will likely refer to themselves as software engineers) with the structural, electrical and manufacturing engineers of other disciplines. But then who is doing the lower level work? The answer is that in the software world, tools have been developed to completely automate the construction phase. These are compilers and build systems (like "make"). In fact, what the developer produces is not an end product, it is not the source code which is delivered to the client. The source code and the makefile form a detailed specification which is given to the build system (which perhaps we might consider to be the "foreman" organising the construction), and the compiler (the "brick-layer") which produce the finished executable machine code. The fact that with sufficient computing resources these tools take a negligible amount of time to run may lead us to forget the importance of the work that they do.
Comparing the work of the compiler to a production line technician seems to fit quite well. The technician's work is fairly mechanical, and if it were cheaper, then they would probably be replaced by a machine. The software world has already passed this stage, delegating the task of translating from source code to executable code to the machine. On the building site, the craftsmen and labourers will most often be contractors, not continually retained by the building firm, but only working on the site on, and only paid for, the days that they are required. This again has parallels with the way that the developers will use the compiler. It is only called upon when needed, and for the rest of the time could be "working" on another project.
| Construction | Automotive | Software |
| Client | Client | Client |
| Architect | Designer | Architect |
| Engineers | Engineers | Developers |
| Foreman | Production manager | Build system |
| Craftsman | Technician | Compiler |
In this revised table, we can see that there is in fact a strong correlation between the different roles of people on different types of engineering teams (within the categories of engineers/developers there may well be some further distinction into junior and senior engineers as befits the project management structure). In general there is a reduction of the creativity involved in the roles as we move down the table, and we may postulate that as technology advances, craftsmen and technicians may be replaced by machines as has already been the case with the lower level activities in the software industry.
The design processes used by each of the teams discussed in the above section are quite varied. When designing a building, the engineers must perform a lot of analysis and calculation so that they know that the structure will be strong enough before they build it. There is no facility for testing it afterwards, discovering that it wasn't designed quite right, knocking it down and starting again. Only one building is ever constructed from a design.
In designing a car, the automotive engineers will test and refine each component individually as well as performing analysis on models. Eventually they will produce a prototype. This prototype will then be tested and the design improved until everything about it is satisfactory. After this, the production line will be set up to mass produce the vehicle.
Different software projects will be run in different ways. When a mass market piece of consumer software is produced to be sold "off the shelf", for example a spreadsheet or a word-processing package, its development will likely involve a lot of prototypes and testing before the final version is released and the cds are copied for distribution. After this it is very difficult to fix any problems that are discovered. This is much like the automotive scenario.
Something closer to the process seen in the construction industry can be seen in the development of the software to run the new air traffic control centre at Swanwick. Here the software had to run correctly and be fully functioning with the first release. There is very little scope for bug fixing and upgrading the system at a later date, or gradually adding features.
If the software is being produced to be run only in one place, say on the servers of a company providing a service through a website, then it is likely that the developers will have fulltime jobs with the company, and so will constantly be making improvements to the system, which, hopefully after a degree of testing, will be released onto the website. As the software is only being run on machines directly under the company's control, this is much easier in this circumstance. This is perhaps analogous to a formula one racing team constantly making improvements to their car between races throughout the season.
By examining the differences and similarities in the approaches taken to designing and building artifacts in different engineering fields, we have come across some interesting parallels. We have seen that the jobs that people do on an engineering project are not substantially different across different disciplines, but that there are substantial differences in the process that is followed depending upon the method of releasing the product, and whether or not something is to be mass produced. We have also noted that it is possible to think about the problems of one domain in terms of another, and this may be a useful device for coming up with novel solutions to problems by thinking "out of the box".