Wiki / Previous PLoPs

Focus Group 3 - Design for Maintenance – Maintenance by Design

"Hardware: those parts of the system you can kick.
Software: those parts of the system you can merely curse" (anon).

Group Leaders:Ofra Homsky and Amir Raveh


A computer, a device, a system or software ceases performing as expected and we call upon the services of the support engineers.

Engineers could deliver better support if a product was designed for maintainability.

No matter how professional, knowledgeable, empathic, intuitive and experienced support engineers are - without the proper tools built into the product their ability to help might be extremely impaired.

How can we improve maintainability? What would you change in designing a product so it could get better support?


The purpose of our focus group is to collect ideas and suggestions for improving the maintenance of products, focusing on building the maintainability into the products and systems from the design phase and throughout the entire development life cycle.


Bring your own stories about resolving problems in systems – it does not matter if you were the person resolving them, or the person experiencing the problem. The story can be about success in problem resolution or about failing to resolve the problem.

As background material, please read in the proceedings of EuroPLoP 2003 Technical Support Patterns (LINK_TBD.pdf).

We would appreciate any issues and responses you encounter while reading the pattern language.

Issues for discussion that we could think of are:

  • Collection of information to help resolve problems : In order to find out what went wrong support engineers need information about what happened with enough details to recreate the problem in the lab or at the programmer's desk. But, keeping detailed logs of events and errors is more likely to slow down the platform and consume limited resources such as disk space. How can a balance be established between no information and too much of it? What mechanisms can you recommend to save the right amount of information until a support engineer can retrieve it?
  • Clear error messages : The typical "General Protection Fault" error message on the dreaded blue screen is an example of how unhelpful and confusing an error message can be. On the other hand, a message that contains no "technical" information may provide no clues as to why something is wrong. How can we balance user-friendliness with technical details?
  • Maintenance toolkit : One way to assist in resolving problems is to provide a set of tools in the standard software installation. What tools do you provide in toolkits in software you participate in building? What tools would you like to see added?
  • Peepholes & Testpoints : While this pattern may help in resolving problems, it may also introduce vulnerability into a system, since this pattern provides points at which data or an event can be injected into the system, bypassing any checks or security mechanisms. How can we provide this problem resolution mechanism without jeopardizing system integrity and security?

And of course: Can you think of patterns that interact or complement those in the paper?

To allow more time for efficient discussion of your suggestions, thoughts and experience, we recommend that you submit these as a position paper by May 29 th 2004.

What we will do

  • To start the focus group, we'll use the collected position papers, stories and thumbnails submitted. We will walk through them, ask questions and clarify our expectations. A first look at the results will show which domains they are applied, or could be applied to. Than we'll vote on a subset to analyze in more detail.

We'll split to work in teams of four or so. Each will examine a specific one of these problems. We'll work in phases, as follows:

  • Identify and write down specific stories where the group members - or other teams we may know of - have encountered the issue. This 'grounds' the discussion, helping us to agree on terms and what we mean by the problem. It'll be important to be fairly disciplined about this, and not to move onto discussing possible solutions until the next step.
  • Discuss possible solutions to the problems. What solutions were tried? Which ones worked? Which alternatives might have worked better?
  • Collect the successful solutions, together with examples of their use, for possible patterns in future.
  • Identify conclusions, and write them up on flip-chart sheets to share with other workshop teams.

We will end with a short discussion of the results with the whole group.


We hope to end the focus group with thumbnails of patterns, illustrating stories and known uses.

  • After the Focus Group, we will collect the results and publish them in the conference proceedings.


Please send your request to join the focus group, and the optional position paper to Amir Raveh [email protected] by May 29th, 2004.


PLoP is a trademark of The Hillside Group, Inc.