OOPSLA 99 Design for Maintenance Workshop

The Workshop

Caution. These are preliminary notes that have not been reviewed by all participants. As such they may contain various errors and biases from the scribe (Pete).

Participants

Although the turnout was small, the participation level was high (and sometimes loud).

Jens Coldewey, Pete McBreen, Neil Harrison, Kurt W Derr, Maximo Prieto, Steffen Schaefer

One very interesting outcome of the workshop was a Software Maintenance Manifesto. This is still very much in draft format but we are hoping to evolve it over the next period (Jens and Neil had the original idea for this during the workshop, and it seemed such a good idea that it was expanded on and has been included as part of the workshop output).

Thoughts on Maintenance

We were split into two schools of thought.

One idea is that developers need to make their system as flexible as possible so that requirements changes can be accommodated with zero code changes. We labeled this the Designed in Flexibility (or Up Front Design) approach.

The other idea was that you start with a simple, evolvable design and let the system emerge from the changing requirements that are presented to the developers. A label for this is the evolving and emergent systems approach.

Up Front design is a higher risk, higher potential reward strategy

For new developments you should be able to tell fairly quickly which approach to take.

When to abstract, when to add flexibility?

Is it economic to combine the two strategies?

Choose depending on circumstances

Timing

Architecture and Design

We discussed some design principles that would allow the Just in Time flexibility approach to work. We came up with nothing really surprising here,

Other Topics that are possibly relevant

Complexity

We need to distinguish between domain and solution complexity. Can a simple solution support a complex domain? Is it possible to add complexity later?

Possibly can partition complex domains so that have a Unix like solution

Would a simple approach paint the project into a corner? (No evidence that you can do this without poor design encapsulation and bad coding practices)

Danger of Big Ball of Mud problem.

Question: Are big systems even possible?

Can we chunk them down into smaller, doable systems?

Genericity: Add where useful vs. simple design.

Project Management/Sponsors

Managers do not appear to understand objects or software

Project management is still based on physical metaphor (Fred Brooks is still relevant and the mistakes he pointed out are still being made today)

Market position (Time to market) vs. maintainable system (but is it really a dichotomy?)

Splitting business and technical responsibilities (as in XP)

"Unrealistic" project goals?

Techniques

UML is not a method or process

No cookbook approaches

Techniques are local

Responsibility driven design and Desert techniques are mandated by the process, they are not independent.

Tools

We need more, sharper tools

Collaborative tools

CASE Design or Documentation tool. (Can possibly be used to check designs for some checklist items)

Version control/test/install tools

Cost justification of tools is difficult

Not all tools are bad, we often use complex tools badly, tools often have large learning curve, so may need a toolsmith

Architecture and Design

Unlike Boehm figures, we are approaching zero cost of change

There are known techniques that can achieve this

Encapsulation, high cohesion, low coupling, zero duplication

Process/environment issue (but have to set this up)

Design principles

Team

Team longevity may be a better indicator of delivery than SEI CMM level

Incenting/encouraging cooperation

need an appropriate process for team size

Who owns/changes code and design

Role assignment

Architecture/development teams as a common failure mode

Individual

How do we reward skills?

Possibly cannot get a skilled team

Motivating retention

Achieving mastery

Applying known techniques

Process

Balancing forces

What problem are you solving?

Do the activities you are undertaking move the project forward?

Is it OK to question the process?

How much waterfall is needed?

How much up front is useful? (OK to get coarse domain knowledge)

How do external forces play (reliability/extensibility/requirements changes)

Design for maintainability

Maintenance is meeting a change in system requirements however we do that or the need to change the code to meet changes in requirements?

Possible concern that design for maintenance increases solution complexity

How good are we at looking into future?

An alternative strategy is to Build simple systems, we can always add complexity later

Less complexity and abstraction

Configurable systems (supports changes without coding)

Build simple system that accommodates change

Pete McBreen, petemcbreen@acm.org