Beyond Green-Field Software: SPLASH Workshop Report

Workshop conclusions

The workshop attendees addressed four main topics:

1. Modernization projects
2. Social issues in reuse and legacy
3. Process and techniques for legacy
4. When not to reuse

Modernization projects

Two goals of modernization: cost savings and business opportunities

Helpful techniques for modernization:

1. Bake-off with multiple options
   • start with an “exploration” - try multiple approaches with some small teams
   • have a “bake-off” of the results
   • choose one way - one of the exploration teams becomes the leaders of the modernization effort
2. Run a single pilot project
   • do a pilot project on a non-critical system
   • do the pilot quickly, learn and expand to riskier work

The bake-off is more expensive, but it gives you more reliable data about which approach is best

Modernization projects have many constraints:

• time, cost/budget, staff
• the need to work in stages
• infrastructure
• outsourcing strategy
• evolution versus revolution
• imagination
• hardware

In many mature applications, it is important for the revised code to be “bug-for-bug compatible” with the legacy code. (You don't always know which bugs the customer relies on.)

Prerequisites for modernization - understanding of the legacy

• how does the system work
• tests
• requirements
• use cases
• discussions with customers and designers

Question: Do you need a visionary or "champion" for a modernization project?

• someone who has the imagination to make it happen

Question: How can we measure the impact of a modernization project?

• estimating future maintenance costs
• assessing future market opportunities

Books:

• Object Oriented Reengineering Patterns, Serge Demeyer
  • book website (free PDF available)
• Clean Code, Robert C. Martin
• Eating the IT Elephant, Richard Hopkins
• Working Effectively with Legacy Code, Michael Feathers

• Restructure101 from Headway Software

Social issues in reuse and legacy

Reuse is an enormous people issue

Conway’s Law applies to reuse and reengineering too

• Conway’s Law (1968) - “Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.”
• original article on Conway's law

Legacy code raises emotional as well as rational issues

• OOPSLA 2003 panel -- Don Roberts had a story of “how long do you milk a dying cow?”
• We have a lot of emotional investment in our legacy systems, and we don't always make rational economic choices.
• From OOPSLA 2003 panel report.

  Don Roberts told a couple of stories based on his wife’s experiences as a veterinarian. She is often asked to treat a farmer’s sick cow, and at times she has to explain to the farmer that the treatment will be very expensive. The reaction of most farmers is that they ask her to shoot the cow - a purely economic choice, because treating the cow will be more expensive than the expected value of the milk the cow will produce in the future. On the other hand, she often is asked to treat seriously ill pet animals (dogs, cats), whose owners are very emotionally attached to their animals.

  The difference between an economic choice and an emotional choice is perfectly valid for animals. But emotional attachment to a piece of legacy software can be quite irrational.

  So... how long do you keep milking a dying cow? In other words, what are the economics of continuing to evolve a software system that is no longer economical to maintain and transform? At some point, management needs to make a decision without being clouded by emotion.

We sometimes say that a project is “modernization” in order to attract talented people to maintenance projects

One good process to consider is to do a “project health check,” which assesses product (documents and code) and the team

Process and techniques for legacy

Documentation techniques that have a low investment cost -- use cases, scenarios, simple class diagrams

Code comprehension tools and techniques: reverse engineering, tools to help explore undocumented code

Patterns and architecture - Facade pattern, wrappers, adapters, inversion of control, dependency injection

People practices - mentoring, convincing managers about risks/benefits, convincing staff that their work environment and working conditions will not deteriorate by reusing rather than always building anew

When not to reuse

Don't try to reuse something that has never been used!

• cancelled projects resurrected as component development - not good

Don't use software that you don't understand - it will get you into trouble.

• understand the data, side-effectxs, temporal/functional interactions, interfaces, and responses
• what Joshua Bloch calls “the contract” (in Effective Java)

Simplify -- be prepared to take things out. Large “reusable components” are less reusable because of bad coupling problems.

• refer to the Separate Ways pattern by Eric Evans

General insights

Reuse, refactoring, and modernization are processes that require a lot of knowledge management

Small automated tests -- and using TDD and ATDD -- can be a big help

We don't teach students to read the code of others

Emotional attachment to legacy

• will we fire the maintainers after reengineering is finished?
• how to capture specialized knowledge (the “swamp guide”)
• difficult to trust new code, even when the legacy system is fragile

Managers get the most “points” for two things:

• a successful startup
• a successful turnaround

Buy versus build decisions

• how flexible are the requirements?
• do you want to customize later?
• integration obstacles
• extension points

Watch out for general components that depend on specific components (see OOPSLA 1997 paper by Margaretha Price on analyzing and measuring reusability)

Wrappers are good for vendor code, but not for open source

• creates a General->Specific link

Managers are tempted to hire outside experts for some problems, rather than investing in their internal people

Defining good interfaces is hard - documenting interfaces is even harder

• the name of an interface doesn't always explain the semantics
• sometimes the source code is the best documentation
• another approach is to use ideas from Domain Driven Design (Eric Evans)

Problems with ROI models

• advocates of new technologies are overly optimistic about the benefits
• we can't always get all of the data to compute ROI
• and the problem might be that managers are unwilling to make a decision, even with real evidence

Instead of ROI, try for “risk reduction”

• a primary motivator for middle management
• what are the risks if we do nothing
• there will always be design debt and competition for scarce resources
• we propose technologies to address the largest number of risks possible

                  Attendees
                  
                  Dennis Mancl
                  Steve Fraser
                  Bill Opdyke
                  Baris Aktop
                  Roger Apsujo
                  Ohad Barzilay
                  Robert Rhonnstad
                  Katrina Sponheim
                  Leo Marland
                  Darren J. McLeod
                  Larry O'Brien
                  Chuck Matthews
                  Werner Wild
                  John M. Brown
                  Sushil Bajracharya
                  Kema Memis
                  Michael John
                  Omar Tanveer