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).
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).
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.
Is it economic to combine the two strategies?
Choose depending on circumstances
We discussed some design principles that would allow the Just in Time flexibility approach to work. We came up with nothing really surprising here,
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.
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?
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.
We need more, sharper 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
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)
Team longevity may be a better indicator of delivery than SEI CMM level
need an appropriate process for team size
Who owns/changes code and design
Architecture/development teams as a common failure mode
How do we reward skills?
Possibly cannot get a skilled team
Applying known techniques
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)
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