07 Chapter 4: System Archeology and Agile Methodology

The Concept of Archeology in Legacy Systems

Archeology as a Methodology

Discourse analysis is being used to critique activities in literate communities. The texts of the communities are analyzed from the viewpoint that these texts are a part of the discourse in the communities. That means the discourse and not the text itself is the focal point of the investigation.

It is not too great a leap to see the problems of a computer system and its code as being amenable to such analysis.

The concepts of layers is a common method of dealing with cultural issues. To branch into the archeology of a system is a new concept. To some extent we use some of the same methods of analysis but with an importantly new perspective.

The methods of Foucault are aimed at analyzing the discourse of a literate group in order see how their discourse has developed and changed over time. He called this archeology because the results of the discourse are similar to that of an archeological study. He also developed the concept of layers in an archeology of the discourse of some field which like standard archeology appear as historical layers in the discourse.

Habermas developed the concept of communicative action which moves discourse analysis into the realm of development. He also develops concepts of meaning in discourse, that allows us to examine the discourse for subtleties of meaning to define and change the discourse. The change is to be used to get agreement on the meaning of words and of concepts in order to lead to an overall agreement.

All this can be used to develop a more dynamic if perhaps less structured systems analysis.

Such a systems analysis can be effective. Particularly in systems where structure has not provided a solution to the issues at hand or that may have caused the very problems we are trying to solve.

The Project:

Washington State had developed a program to provide Deaf and Hard of Hearing with equipment that would allow them to use Telephone services. The original idea was to give the equipment to any person that needed it. The particular equipment would depend on the needs of that person.

The project given to me was aimed at developing a record of inventory. As time went by the program found they needed to know where the inventory was and how much was on hand or in the process of delivery and where. The delivery involved trainers that would deliver the equipment and train the client in its use. Thus trainers had an extensive amount of stock. Also trainers were allowed to make decisions altering the specific equipment to be given, if it was obvious on meeting the client that the wrong equipment was specified.

The Project s as Defined to Me

I was told that I was to find the inventory but the inventory really could not be found because the system design was never meant to keep track of inventory. The system was too old and fragile to expect to make any large changes. It would be enough to make some minor changes that made the system work better for the system users.

Development

As I viewed the original code there appeared to be a great similarity between the code and an archeological site.

It was a mess. But, as in archeology, the key to developing an understanding of the jumble, begins with recognizing layers or historical layers. I found I needed to find a means to unravel the system. It was just a jumble until I began to recognize layers. This method I borrowed from Foucault. This is systems archeology.

The system users are part of this system, also. They are part of the processing or, as I call it, part of the discourse that makes the system what it is. The system users know the system history and can even point to issues that were earlier changes. All this can help delineate the layers of the system. I had to know the layers well so I would know what went together and what was separate.

Archeology of Legacy Code

The screens of the project are the way the code communicates with the system users. Screen design issues can be clues to the layers in the system. The users recognize changes in these screens where they would have no clue what changes were made in the code. These screen changes are associated with specific layers and help reveal layers in the system.

Internal Context Matching for Meaning

Discourse with the system users and managers can help to solve problems in the system. The discourse can also clarify problems with how processes within the system are viewed and thus how it is named. By clarifying that the present use of the destination of inventory in the discourse referred to a type of place rather than an actual place, it became clear that the destinations all had to be redefined. It took time to change the concept of inventory name from type to place. As the inventory destination definitions were changed quite often over time (in the application and in the thinking of the users of the system), it was as though the inventory appeared. This methodology was borrowed from Habermas. This is language pragmatics.

Through the Looking Glass

The inventory begins to appear from our mound of rubbish. We solved a problem that the structured approach could not have solved. Recognizing the layers within the system allowed us to change complex code with less threat of side effects. Tying the layers within the code with layers in the whole system, including the screens and the systems users, helped to associate the problems within the code with the overall problems of the system.

The system began to produce inventory reports. There were attempts to keep track of inventory on a small scale using some pencil and paper methods. These were used to get an idea of how our inventory system stacked up to other methods of measure. We found that all the paper and pencil methods were within one or two units of the values we got from the system.

When we compared how (dates and time) the paper and pencil values were recorded and when the system values were recorded; the two were not recorded on the same set of days partly because two different ways of doing the recording; one doing the input to the system, the other doing the paper and pencil recording. Thus we became very confident that the system inventory was quite accurate.

Dr. Jerome Heath

Google Books: Hermeneutics in Agile System Development