COBOL, and the gold dust of business process

A couple of events today dovetailed, and provided some food for thought. As the day was beginning, and before the office really started to fill, I was speaking to a developer who was enthusing about testing and refactoring old code. After he talked about incrementally bringing out the intent of the code he rounded off with “…and then you get to the real gold dust, which is the business process”. I liked that picture, and it stuck in my mind. An hour or so later I found myself sitting with another developer helping him put unit tests around COBOL code. By today’s standards COBOL is astonishingly clunky, and it was near-impossible to see the business process for all the low-level mechanics that filled the screen. And yet COBOL declares itself to be the Common Business-Oriented Language. In theory I should have seen a screen full of gold dust.

In case you’re wondering what COBOL looks like, here’s an excerpt of a program which unpacks a CSV file:

PROCEDURE DIVISION.
Begin.
   OPEN INPUT VarLengthRecFile
   READ VarLengthRecFile
      AT END SET EndOfFile TO TRUE
   END-READ
   PERFORM UNTIL EndOfFile
      MOVE ZEROS TO InsertSupplierCounts
*     First find the actual length of the record
      PERFORM VARYING StringEnd FROM 78 BY -1
              UNTIL RemainingRec(StringEnd:1) NOT = SPACE
      END-PERFORM
      IF InsertSupplier
         UNSTRING RemainingRec(1:StringEnd) DELIMITED BY ","
             INTO TransDate        COUNT IN DateCount
                  Supplier-Code    COUNT IN SuppCodeCount
                  Supplier-Name    COUNT IN SuppNameCount
                  Supplier-Address COUNT IN SuppAdrCount
         END-UNSTRING
         PERFORM CheckForErrors
        ELSE
          IF NOT ValidTypeCode
             DISPLAY SPACE
             DISPLAY "Record = " VarLenRec(1:70)
             DISPLAY "Type code is not valid"
          END-IF
      END-IF
      READ VarLengthRecFile
         AT END SET EndOfFile TO TRUE
      END-READ
   END-PERFORM
   CLOSE VarLengthRecFile
   STOP RUN.

We could laugh today at how far COBOL is from expressing business ideas, but that would be foolish. I’m confident its inventors were smarter than me; perhaps they were even smarter you. The truth is that the technologies we consider today to elevate and express business processes will themselves be smirked at in decades to come. This is what the University of Limerick says about COBOL on its computer science course:

One of the design goals for COBOL was to make it possible for non-programmers such as supervisors, managers and users, to read and understand COBOL code. […] It encourages a simple straightforward programming style. Curiously enough though, despite its limitations, COBOL has proven itself to be well suited to its targeted problem domain (business computing).

If you don’t believe that now be warned that technologists of the future may not believe your justification of your favourite business-oriented technology today. COBOL was created at a time when technology played a different role in business, and when business people’s relationship with technology was also different. We can safely assume that will change again. The concerns our technologies put front and centre today will melt away in years to come.

In the end, our business’s technology is there in service of our business. And our business has to change. If we are to improve our business or even if we are just to cope with growth or changing market context, then our business will need to change and our technology has to handle that.

Our technology components must be able to flex according to our changing business processes—they should certainly not get in the way of that change. That may mean we will need to change the way a component works, or it may mean we will need to replace it entirely. If it gets in the way of that then it gets in the way of us being able to change our business for the better. And it doesn’t matter which decade the technology was introduced.