Complexity in Design 2005

I saw this once before and thought it interesting, but now that I've read it again (weeks later, after a glass of wine), I find it heart-rending. Here's an entire conference dedicated to both the customers of my company, and the employees at my company, many of whom used to be customers and now have to support other customers in their new role as software engineers: CiD: Complexity in Design 2005. Too bad it's in Glasgow in March (what were they thinking?).

For example, mechanical engineers must develop products that go faster, require less maintenance, use less raw materials than ever before. These demands are compounded by the increasing emphasis on mathematical modelling and simulation rather than destructive testing. Similarly, software engineers are being asked to develop systems that interact with these devices and with human operators. Increasingly the demands of developing safety-critical systems are being exacerbated by the need to produce `band-aid' software that addresses known problems in the underlying mechanical and materials engineering or that addresses underlying human factors problems in the usability of an application.

For instance, re-use simplifies many aspects of complex systems design. These techniques also carry important overheads; it can be hard to ensure that an implementation satisfies the intended requirements within its new context of use. This applies to software engineering just as it does to mechanical engineering. These comments may also, arguably, be applied to the reuse of design processes and teams. Similarly, risk assessment has been used to guide the development of many previous generations of complex systems. However, the increasing integration of large scale application processes and the inter-disciplinary nature of many engineering endeavours makes it hard to sustain this approach from individual component reliability up to the `systems' level.