ReverseForwards

PublicReengineering Wiki

(aka KnowYourStuff or KnowTheEnemy ).
Context You are about to start a reengineering project. Your team has a comprehensive specification for the intended target system, but does not fully understand the legacy or the domain in which the legacy operates.

Whilst following the specification without embellishment may satisfy your contractual obligations, it will not fully satisfy your customers/users. The specification is unlikely to cover all the subtleties of behaviour, knowledge and culture that have been evolving in the legacy over time. You want the reengineered artefact to take account of as many requirements as possible, but you need to start programming as soon as possible to meet project deadlines.

Problem How can the reengineered artefact capture as many requirement as possible?
Solution Learn as much as possible about the legacy and its domain before and during the execution of the reengineering project. First, encourage the team to study the legacy's code and documentation. Provide incentives for this at their job reviews. Observe users, interview domain/legacy experts and produce prototypes. Recruit one or more domain/legacy experts onto the project team. Hold workshops to educate the staff in the history of the legacy and the domain.
Consequences Specifications make assumptions which may not be obvious to everyone. A contrived and flippant example could be that the specification for a new model of luxury motor car does not explicitly state that there should be four wheels; one at each corner. The designers then assume that they can make savings by having three wheels. Consumers reject the concept and the product becomes un-sellable.

Taking time out to learn about the domain and the legacy through reading code and documentation, observation, interviews, workshops,  and producing prototypes will add cost and time to the project. On the other hand, such activities should reduce the risk of missing requirements and will increase the quality of the reengineered artefact. 

Programmers are often reluctant to read documentation (particularly if they suspect it is out of date) and code (particularly if it is poorly structured or written in a language they are not familiar with). By providing incentives, they are more likely to invest the necessary time than if were merely instructed to do so. However, such incentives may add cost to the project.

Since learning can take place throughout the project as well as at the beginning, you can start producing code earlier. As you understanding grows, you are better placed to ask the right questions and so improve your understanding further. However, you could have to re-work some aspect of the reengineered system after you discover an important requirement. On the other hand, you may well have adopted the concept of throwing prototypes away (an idea popularised by Brooks95 ). In which case, covering the same ground is already an established part of the project's methodology.

An expert in the development team can provide instant and unsolicited feedback on issues. They are also less likely to provide misleading or incomplete advice, than the expert interviewee outside the team, since they have a professional interest in seeing the project succeed.

Workshops are a useful means to deliver expertise to the team and also allow them to communicate their own knowledge to the group. However, they do require a substantial investment of time from all the staff.

The issue of not adding extra time and costs to the project has not been fully resolved. Having made the investment, however, it is likely that it will pay off in less time being spent testing, debugging and seeking customer/user acceptance at the end of the project.

Related Patterns DemeyerEtAl99 provide a reverse engineering patterns language to help understand the legacy quickly and effectively. Closely related patterns are MuseumManager and LowEffortUserInterfaceReengineering .
Known Uses TilleySmith96, FantaRajlich98, BrayHess95, PlaisantEtAl97, RuhlGunn91 and Adolph96 all advocate reverse engineering before and/or during a reengineering project. More generally, Sneed91 equates a thorough understanding of the domain and existing systems to project success.


Related pages: ReengineeringPatterns

This page last edited on 5 January 2000
 
 
  • Search for: