Modelling for Maintainability - SPA Cambridge session
Some of you may know that I co-organise SPA Cambridge where we have a regular software talk led by an industry or academic expert. Our latest session, Modelling for Maintainability, was presented by Andrew Watson of OMG on 14th June. Andrew’s slides are available here.
After a short sermon on standards and a review of the CHAOS reports, Andrew provided some background on software maintenance costs as a proportion of total costs of software projects quoting from various studies:
- > 90% Moad 1990
- 60-70% Huff 1990
- 75% Eastwood 1993
- > 90%, Erlikch 2000
Maintenance is hard because of lack of documentation, changing platforms, changing program structure and the sheer difficulty developers have of understanding each others code and old code. (> 50% of maintenance time is spent understanding code). Furthermore, the volume of code under maintenance is doubling every seven years - Andrew’s claim, based on work by Paul A. Strassmann, is that we’ve now reached the point where we can no longer afford to throw away our existing software assets when we change our underlying programming technologies.
OMG’s solution (and that of others) is to raise the level of abstraction from code to higher-level models and Andrew provided the results of various studies to help support the claim that doing this would lead to significant benefits.
Models (of programs), it is claimed, will be easier to maintain than programs themselves. (There was some good discussion on whether this would be the case and the risk of lock-in to particular modelling paradigms.)
It’s also worth mentioning one anti-pattern that is occurring now and is likely to occur every time the level of abstraction is raised in this way. The antipattern is the rearguard action fought by those who claim that we will never be able to provide a sufficiently rich modelling tool and sufficiently rich optimisation tools to map models to lower levels.
This argument was used by assembly language programmers to resist the introduction of high-level languages and while say 5% of assembly language programmers could write code that is better than could be generated by a compiler in say 5% of cases the fact is that for most programmers, most of the time the compiler will do better.
Now I’m not saying that the current crop of Code Generators are at this state of development, although some are sufficiently good that they should be considered, at least for work in well-defined domains.
Thanks to Andrew for an interesting and informative session. SPA Cambridge’s next meeting is on September 13th 2006.
