Maintainable Software, Adventure 1

This is the first in a series of at least three projects which most strongly influenced my views of software maintenance.  I have titled them Adventures in Software Maintenance.

  Denison Mines Open pit mining, washing plant etc.

The adventure here is that until about half way through the project (several months) I did not have anything close to a full set of requirements.  The requirements were given one small part at a time with coding and testing done before the next requirement was given.

While working for Computer Sciences Canada in the late 1970s, I was given the assignment to be a consultant and contract programmer for a company then known as Denison Mines. At the first meeting the man who was to be my manager at Denison Mines told me that he knew very little about computers but was confident that they could solve his problems.

The first assignment was in essence to create a ‘graph’ of a curve with two inflection points and to do this for several hundred data sets which had only two data points.  I of course having studied such things in college told him it could not be done.  He said we were going to do it anyway because each pair of data points cost several thousand dollars to produce.  We did it in a few months by using a few complete data sets, some other empirical data and the help of a Japanese mining engineer they brought in from japan.

Over the course of several months the manager kept adding other things which needed to be done and added to the growing program, such as adding a mathematical model for a coal washing plant, a mathematical model of the geology of a few mountains and algorithms for designing open pit mines.

After a few visits it became obvious that this incremental requirement discovery process was going to continue and it was going to be impractical to keep re-writing the program. The solution was to design a simple command reader which would read a command (from a file) then make the appropriate subroutine calls.  There was too much data to pass into the subroutines so the application data was read into global structures and the routines manipulated the data in those structures.

Looking back on this project from a maintainability perspective, the most volatile program area was in the command interpreter where new commands were added.  This worked because the highest level flow control was shifted outside of the program and into the command file (there were no conditional or looping statements in this language). The second most volatile area was the data structures.  Changes were made to array sizes or to add new arrays and entries in the common blocks or new common blocks.  In more modern languages the changes to the common blocks would be to add fields in a record or data only module. The least volatile area was the computational subroutines or algorithmic code as I now call it.  The changes most often were to add routines to execute new commands.

One side effect of the command stream architecture was that depth of subroutine/function calls was very shallow, seldom going more than a couple of levels.  This in turn made it easier to test new code.

The result of this design/architecture was that very little maintenance work was done or needed even after several years.  A historical foot note is that this program was used to design two major open pit mines and the associated coal washing plants. For more information about this see http://en.wikipedia.org/wiki/Tumbler_Ridge,_British_Columbia and this http://www.windsorstar.com/cms/binary/6531189.jpg?size=640x420 and this http://www.ridgesentinel.com/wp-content/uploads/2012/04/WEB-04-April-27-Quintette-and-PH.jpg  

Summary of things done and learned

o   Language: FORTRAN using block common (data only single instance records)

o   The value of validating (e.g. range checking) application data as it is read

§  This allowed the algorithmic code to be as simple as possible by focusing exclusively on processing the data

o   The value of using a user input stream for top level control

§  This reduced the effort required to test new code by allowing execution of new subroutines to be isolated from existing code

§  This enabled changes caused by the introduction of new functionality to be very localized within the program. Most changes were limited to the new subroutines and a simple addition to the command interpreter.

o   The value of separating control and computational (algorithmic) code

§  This was mostly a side effect of the command stream architecture

o   The value of storing application data in global space

§  Because most of the data was stored in arrays, this allowed a kind of ‘pipeline’ processing and all but eliminated the passing data up and down the calling stack.  The trade-off is that more than ordinary attention must be paid to how data is organized and that subroutines only work on very specific data elements.

The application data naturally occurred in one and two dimensional arrays. The raw geological data was presented as a set of vectors for each drill hole, a location followed by a vector of numbers representing what was found at varying depths. This data could then be filtered and processed to produce ‘topology’ maps or simplified arrays representing seams of coal which had specific qualities which could be written to a file for later processing and/or producing various reports.  In all cases original input data was never altered.