SPA Conference session: Software as an Engineering Material? | |||
| One-line description: | What are the "material properties" of code that guide design decisions? | ||
| Session format: | 75 minute Workshop (150 minute [read about the different session types] | ||
| Abstract: | Attempts to promote “software engineering” have tended to founder. Often they are based on a fundamental misunderstand of how established "engineering" disciplines work. This session will attempt to explore one possible correction for this, by exploring what might be the "material properties" of code (by analogy with stiffness, toughness, harness and other properties of engineering materials) and the effects these might have on design tradeoffs in software construction. Attendees will mine from their collective experience the properties of code (languages, technology stacks, etc) which might be analogous to material properties like stiffness or toughness and examine how those properties might influence design. | ||
| Audience background: | Anyone who builds software for a living (or even for fun) will have something to contribute, and will be capable of learning something interesting and hopefully useful. | ||
| Benefits of participating: | Attempts to promote “software engineering” have tended to founder, for a number of reasons. These include: confusion about engineering vs manufacturing; mistaking non-essential characteristics of engineering practice with the essence of engineering thought; wildly optimistic notions about the performance of better established branches of engineering as regards timeliness, cost over–runs and so forth when approaching novel problems. The worst aspect of misguided “software engineering” however, has been around the idea of applying so–called “best practices” to achieve supposedly optimal solutions. In fact, software engineering, like any other branch of engineering, should be about tradeoffs, compromises and finding the least bad solution that only just works as cheaply as possible. As the syllabus for Robert Chatley's Software Engineering module at Imperial says: “from an engineering standpoint, we are concerned with the assessment and balancing of forces that may affect our design decisions in solving a particular problem. There are likely many possible designs that solve a particular problem, how can we choose between them?” How indeed? In Civil, Mechanical and Electrical engineering one important factor as the material properties of the various substances that can be used to implement a solution. For example, aluminium affords a different set of trade–offs in, say, the design of a bicycle frame as does steel, or carbon fibre reinforced polymer. In this session attendees will consider the stuff of software systems as an engineering material: what is easy to do with it? What is hard? What class of solutions is cheap an easy to implement in one language or technology and what hard? What sort of trade-offs do the various technologies that attendees know force us to make? As a result (all being well) they may gain an improved facility in making beneficial tradeoffs in program design. | ||
| Materials provided: | A simple example from mechanical engineering of the effect which material properties have on design choices: say, what's reasonable in an aluminium bicycle frame vs a steel one. | ||
| Process: | After an introduction to the concept, and an example of material properties in material design, there will be a whole group brainstorm of initial ideas which will be developed in small groups. Each group will create a one–page poster illustrating their conclusions to present back to the whole group. | ||
| Detailed timetable: | Minute From To 0 5 Intros 5 20 Example of material properties in mechanical design 20 35 Group brainstorm: what are candidate "material properties" for code? 35 65 Group work on candidates: what sort of design decisions do they drive? 65 75 Each group presents its poster 75 Close | ||
| Outputs: | Posters summarizing the conclusions of each group as to the kind of design decisions that a candidate "material property" might afford in software design | ||
| History: | New session, however, it will be run as an internal workshop with my colleagues at work before Spa. | ||
| Presenters | |||
| 1. Keith Braithwaite Zuhlke Ltd |
2. | 3. | |