![]() |
![]() |
![]() |
![]() |
![]() |
|
![]() |
![]() |
![]() SPLASH 2011 Workshop |
![]() |
||
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|||||
![]() |
![]() |
||||
![]() |
![]() |
||||
![]() |
![]() |
SPLASH 2011 workshop report
|
![]() |
![]() |
![]() |
||||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Beyond Green-Field Software: SPLASH Workshop ReportSPLASH 2011, Portland, OROctober 23, 2011 Workshop conclusionsThe workshop attendees addressed four main topics:
Modernization projectsTwo goals of modernization: cost savings and business opportunities Helpful techniques for modernization:
The bake-off is more expensive, but it gives you more reliable data about which approach is best Modernization projects have many constraints:
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
Question: Do you need a visionary or "champion" for a modernization project?
Question: How can we measure the impact of a modernization project?
Books:
Social issues in reuse and legacyReuse is an enormous people issue Conway’s Law applies to reuse and reengineering too
Legacy code raises emotional as well as rational issues
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 legacyDocumentation 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 reuseDon't try to reuse something that has never been used!
Don't use software that you don't understand - it will get you into trouble.
Simplify -- be prepared to take things out. Large “reusable components” are less reusable because of bad coupling problems.
General insightsReuse, 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
Managers get the most “points” for two things:
Buy versus build decisions
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
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
Problems with ROI models
Instead of ROI, try for “risk reduction”
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 |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
||||
![]() |
![]() |
|
![]() |
![]() |
![]() |
||||
|
||||
![]() |
||||
![]() |
||||