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
Motivation
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?
Purpose
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.
Preparation
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.
Results
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.
Submission
Please send your request to join the focus group, and the optional
position paper to Amir Raveh amirr@systems-view.co.il by
May 29th, 2004.
