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.