Programming in the Large

Before getting back to technical topics, I thought it worth a few lines to consider the programming environment and how it relates to programming technique.

When I was starting to program, the IBM Midrange (with the System/34 as its current representative) was pointed at small business. Its programming language, RPGII, was not viewed as a highly sophisticated tool. People without a Computer Science background could be expected to learn it without a great deal of fanfare. A common way to start was to begin as a computer operator and work your way up.

I suspect that those days are gone forever. The days when you would give the operator a manual and some programs to read are likely done. There are high expectations for programmers these days; if there are entry-level positions, they are well hidden; and those are probably reserved for those with at least some background in college-level courses.

The sophistication of the code also at times left something to be desired. More programmers were needed than could be generated by college, and so their techniques were not always clear. That was especially true with RPG II, which did not have structured operators (IF - ENDIF, etc.). Code was produced of the sort that positively gives me a headache today. A headache to maintain- but it worked.

And so we read today of sophisticated techniques derived from our study of other programming languages. Some are good, others not so good. But more and more sophistication is being demanded. And that can be a good thing.

But is zeal to pursue all these techniques a good thing? As always, the answer is, not always. If your needs are sophisticated, by all means, keep on pushing. But what if you don’t need these techniques? What if the business you support is profitable without them? Is it really a bad thing if you are not an early adopter?

The place I work now fits those criteria. It has been on the IBM midrange for over 30 years. Some of the programs are that old, too. Do you scrap code just because it’s “old”? No. You may try to improve it as time is available and the need arises, but first of all the business must be supported effectively. It would be a waste of time to try to shoehorn a new technique involving user spaces and message queues when it simply is not necessary. If some new technology will demonstrably advance the business, we get it.

So my job is not to be an early adopter, but to support the business, make improvements where I can, but not feel deprived if I am unable to employ some sexy new subroutine or program calling technique. The geek in me wants to try everything I read in the various technical forums, but the pragmatist in me tells me that I cannot do it. We just got a new machine with 13 times the space and over 20 times the speed of the old one; that ought to keep me interested for quite a while. We are connected to the Internet, but not directly; so many of the fancy new features of RPG that allow direct connect to the Internet simply are not needed. My co-worker does not have my RPG background, but I think he knows a lot and is learning more; his programming abilities go beyond RPG to the point that I can only envy them, not emulate them; I have neither the time nor the energy to do so. But his energy energizes me.

Updating code calls for patience. That is a virtue. I am not being paid so I can be entertained; I am being paid to create a positive business result for my employer; as long as I am constructive and keep on learning, I will be happy. I am not a small piece of a big puzzle; I am a big piece of a small one.

One Response to “Programming in the Large”

  1. Hillary Martin Says:

    Good read, thanks for the information, it was really informative.

Leave a Reply