It Probably Seemed Like a Good Idea at the Time

One of my guilty pleasures is the leisurely breakfast. The best ones include fresh ground coffee (grinding the beans just before you brew), a breakfast pastry and a fat stack of daily newspapers to read. The newspaper part is key. We are voracious readers, my wife and I. We subscribe to two daily newspapers and get a few weeklies as well. Saturdays’ are the best – there is no rush to get out the door and the papers are especially thick, testing the breaking strength of the elastic bands that keep them from exploding on my front porch.

With this morning’s stack of papers at my elbow, and a steaming java in my fist, my eyes drifted from article to article forgetting the fluffy stuff seconds after reading them. I was leafing through the careers section of the Globe when my eye fell on a small ad on the bottom of one of the back pages. It was an ad for a firm looking for COBOL programmers.

Ad for COBOL Programmers

COBOL?

Now for those readers who are too young to know, COBOL (COmmon Business Oriented Language) was developed in 1959 and is one of the earliest high-level programming languages. Wikipedia says that it was designed to run administrative and business applications and the key developers were the US government and big military contractors. Ironically, it was originally proposed by a group that called itself The Short Range Committee which was formed to recommend a quick approach to a common business language.

Even when I was in university in the 80’s, COBOL was the butt of jokes and much derision. COBOL programming was a domain of the aged, linear-thinking programmers who typically came to their profession from the faculties of Math, Physics, etc. — without the benefit of modern computer science education. It was a programming back-water, using ancient technology and methodologies, always presenting barriers to integration.

Core Dump

The ad made me think. Here we are nearly 50-years later and the marketplace is still looking for people that have the ability to “analyze computer core dumps” and are “proficient in JCL” (Job Control Language). This must be a very small, expensive and dwindling pool of people that the recruiter is trying to attract. It reads more like a desperate plea than a job ad.

Reflecting on this with leasure that only Saturday morning can bring, I thought of the systems we are building at OTN (both software and hardware). What will our systems be like to support in 10-years — never mind 50? While true that technology can have a very short life-cycle, the opposite is also often true. Are we building systems that are supportable in the long-run or, encouraged to “just get ‘er done”, are we pushing a major headache to the next generation of computer professional? There is no question that we must be quick to satisfy the clinical and operational need of our customers (internal and external). Responsiveness and innovation are highly valued. But in the light of this advertisement for computer professionals knowledgeable in technology developed by a Short Range Committee, I think we must also look to the long-term. The solutions we develop today will be the legacy systems of tomorrow. For everyone’s sake, we have to be sure to create solutions which will stand the test of time.
More information at: http://en.wikipedia.org/wiki/Cobol

Discover more from Ron Riesenbach’s Blog

Subscribe to get the latest posts sent to your email.

One response to “It Probably Seemed Like a Good Idea at the Time”

Steve

January 16, 2009 at 10:05 am

Hi Ron – I enjoyed reading your blog, this entry in particular, as one of those “linear-thinking programmers” who indeed came to their profession from the faculty of Math and encountered some of the snobbishness you allude to among the software purists 🙂

Knowing how much to invest today in maintainability, extensibility, serviceability, and fire-proofing for tomorrow is one of the key tests of judgment for CxO’s responsible for technology development and each new generation of business leaders has to learn the same lessons – usually the hard way. It’s surprising how often we are deluded into thinking that because enabling technology has increased the power and reach of our applications, we can somehow take shortcuts on how we build systems and still expect to avoid the pitfalls that still hold the remains of the previous generations’ failures. But the opposite extreme also fails – spending so long setting up processes and infrastructure designed to avoid pitfalls that your system never sees the light of day.

Reflecting on our industry’s short but dense history is a worthwhile activity; it helps bring the forest back into focus, and the paths often emerge more clearly.

Reply