Uninitialized storage (2)

It is generally a Very Bad Idea to make any assumptions about the contents of uninitialized storage.

What might work today may fail miserably tomorrow, without warning and without apparent cause.

If you care about it, then initialize it.

Application entropy

If you wait long enough, people will start treating a bug as a feature.  Then you can't fix it because you'll break their application.  Sigh.  I have seen this type of application entropy many times.

Business programmers

At the risk of stating the obvious, COBOL programmers work in a business environment, and in that environment people are rewarded more for their business acumen than their facility with nested IF statements. If you can charm the user and convince him that you understand his needs and that you know how to meet them, then it doesn't matter if you go back to your desk and write crappy code.  As long as you deliver something that more-or-less works in a more-or-less timely manner, you will be well regarded and rewarded.

Many (perhaps most) programmers in a business environment are not there for the long haul.  Programming is merely a phase they have to go through at the entry level.

Business programmers fall into the following groups:

1. Managers in waiting.  To this group, programming is just a step on the career ladder.  This is a large group (maybe 25%).  This group cares little about the code they develop, other than it meets company standards and is delivered on time.
2. Business analysts in training.  This group cares more about the company's business than about the programs that support it.  This is the largest group,  and they eventually abandon programming to become full-time business analysts or end users (about 50%).   This group regards programming as utter drudgery, and tend to delegate it to junior team members whenever they can..
3. Clerks in training.  This group does what they're told to do, no more no less.   A smaller group (about 15%).  This group is capable of producing good code, if they're given detailed specifications and good sample code to work from.
4. Technicians.  This group see programming as a profession (or at least a skilled trade) that they can take pride in.   A small group (10%), they tend not to care much about the business they are supporting.  Even though they work with COBOL and can use it creatively, many of them have bought into the myth that it is a Creaky Obsolescent Boring Old Language and yearn to move on to other technologies.
   

ISPF productivity

I love ISPF, I really do.  The Editor in particular is a brilliant piece of work, and in my opinion represents the gold standard for text-based editors.  ISPF also provides a very rich API so those that are conversant with ISPF dialog progamming can create useful and sometimes very complex applications. Yeah, those applications are text-based, but since most mainframe programming is done in a text-based world that doesn't matter.

I have written many such applications, and truth be told, it's a lot more fun to write ISPF Dialogs than to write Cobol code.  

Still, ISPF has its shortcomings.  The product uses hierarchical menus that require skill and experience to navigate.  To be sure, there are many short cuts, but it takes time to learn them.  Also, it does not provide a convenient mechanism for organizing the myriad of data sets, DB2 tables, IMS data bases and TSO commands that the programmer has to cope with every day.

I once wrote an ISPF Dialog application that helped me manage all of that stuff, and I was amazed how much time you could save if you aren't constantly searching for half-remembered data set names.   I've used such a tool for many years now, but more recently I've been relying on a commercial product called Simplist, which is way better than anything I've been able to write for myself. It's not free, but it's not expensive either.  I highly recommend it.

Don't believe me?  This guy likes it too.

Disclaimer: I have written about SimpList on several occasions.  I would like to point out that I have no financial interest in SimpList or any other commercial software product.  My opinion is that of an experienced mainframe developer and consultant, not a product shill.  My product review was originally published in Technical Support, the official journal of the Network and Systems Professionals Association (NaSPA).

Some recent Dilberts

Like many in the IT business, I am a big fan of Dilbert, not just because it's funny, but because it sometimes hits close to home.

Here are a couple of recent strips that I've enjoyed:

Guesstimating

Skills utilization

ISPF weirdness

It's not a bad idea to add an explanatory line near the top of each scrollable HELP panel:

"Press LEFT and RIGHT to scroll up and down"

Or, depending on your audience:

"Press LEFT and RIGHT to scroll up and down. No, I am not kidding."

Risk-averse programming

In my experience,  there are a lot of COBOL programmers who don't give a damn about programming either as an art form or as scientific discipline (take your pick).  They spend their days attending endless meetings with business users trying to tease out system requirements from endless discussions that go round and round forever....   At the end of  each day, they don't sign on to comp.lang.cobol to debate the merits of Sections vs Paragraphs.  To them, programming is a just a chore that they have to do in order to get the end result the user wants.

Generally, business programmers are given the following objectives from their manager (in order of importance):

1. Don't screw up
2. Deliver it on time
   
3. Deliver what the user wants
   

From the users, they get the following objectives:

1. Don't screw up
2. Deliver what I want
3. Deliver it on time
   

I think this breeds a very conservative, risk-averse programmer, for whom avoidance of error is the primary concern.  Don't tell him/her about EVALUATE, he/she knows that nested IFs work. 

Victorian Internet

There are some fascinating parallels between the 19th century telegraph system and the 21st century Internet.

Rules for young drivers

Ontario has a graduated licensing system. The initial stage is G1, where the new driver must be accompanied by fully licensed driver. G2 is the next level, where the driver is allowed most of the privileges of a fully licensed driver, with some restrictions.

We've had two sons go through this process, and I'd like to share some of the rules that we imposed, above and beyond what the law says.

Here are Mom and Dad's G2 rules:

• No solo highway driving (ie freeways and other major highways)
• No solo night driving (not very practical in the winter, but workable in the summer. We eased this restriction after a month or two)
• No passengers other than family members and a few trusted friends. In the case of trusted friends, only one of them at a time.
• The 'Trusted friends list' is subject to parental approval.
• All passengers MUST WEAR SEAT BELTS. No excuses, no exceptions. Anyone who refuses to co-operate must be refused a ride, and will be dropped from the 'trusted friends' list.
• Passengers must also have 0% blood alcohol. A young G2 driver is not ready to be a designated driver.
• Never, ever, take the car without permission.
• We reserve the right to veto time, destination, and passengers.
• You will run errands when requested. This includes driving siblings and getting gas.
• At our discretion, you will check in with us when you arrive at your destination. (This is a good time to get him a cell phone, if he doesn't already have one)
• Any ticket, no matter how trivial, will result in the suspension of driving privileges. No excuses, no exceptions, no appeal.
• Ditto for accidents. (We never had to put this one to the test...thank goodness. This may seem unreasonable, but the rule reminds them that they have had defensive driving training and should know how to avoid accidents, even if they technically are not at fault.)
• No eating or drinking while driving. Young drivers need to pay attention to the road at all times.
• No cell phone usage while driving. (Now illegal in Ontario).

Maintenance: Make it Right!

When faced with doing program maintenance, my personal philosophy is to try to leave the code a little better than I found it.

This goes beyond merely making the requested changes. Maintenance is a good time to beef up the program comments, untangle twisted logic (be careful with that one!) and change cryptic paragraph and variable names.

And, most importantly, take the time to review the error and exception handling. If inadequate, don't just ignore it and move on, make it right!*

A wise man once said to me: "Don't tell me how it works, tell me how it fails."


* Apologies to Mike Holmes