The OOPSLA 99 workshop description is here.
How the workshop went, and the resulting Maintenance Manifesto have been posted
To participate in this workshop please read the Call for Participation. The position papers are posted here.
We often claim that Object Technology makes systems more maintainable, but what does that really mean? What is it about objects that makes it easy to maintain a system? Identifying maintenance as a design priority is especially important with the moves to create a "standard" development process for object technology, since all too often the developers in the field forget to report back on what actually works. As an example think about the number of project teams who are always having to apologize for not having enough documentation. Who gets to define enough? Is a track record of 4 years of increasing sales an indicator that the team has enough documentation, or a sign that they are soon going to fail unless they stop and document what they have got? The concept behind design for maintenance has analogues in other engineering fields such as "Design for Manufacture". The workshop will seek to identify other priorities for OO development such as "design for testability" and the effects that these priorities would have on the economics of the delivered system.
One of the interesting aspects about the Y2K fiasco is that it has focused attention on the question of "What is the economic life of a system?" Maybe there is no such thing as a legacy system, maybe there are just systems that have been well maintained and systems that have fallen into disrepair.
This workshop will bring together practitioners who have been actively involved in the development and enhancement of a system over several years. The challenge is to identify common development processes and practices that support and enable software maintenance.
The main goal of this workshop is to challenge individuals who are involved in software development to design for maintenance, and to challenge assumptions about software development methodologies. In order to achieve this goal, we will be developing several anecdotal models of what has enabled teams to be successful in shipping and supporting systems.
As a group, we will strive to identify essential elements that must be recognized and addressed in any software development process together with any training or team issues that arise from that.
Organizers:
Pete McBreen, McBreen.Consulting, Email: petemcbreen@acm.org
Jens Coldewey, Coldewey Consulting, Email: jens_coldewey@acm.org Web http://www.coldewey.com/
Russel Bryant, Ebo Consulting, Email: russ@eboworld.com
Pete McBreen, petemcbreen@acm.org