High Tech and Literacy

I don't know what it is, but those who work in the high tech field generally have a very poor grasp of written English. Well, when I think about it, so do most people I've run across. But, you'd think (hope?) that those who've gone beyond secondary school would be able to put together a coherent sentence. Alas, that appears to be the exception, not the rule.

Documentation is vital in the computer world. Without detailed instructions to accompany them, many programs would remain underutilized and difficult to master. That goes for all stages of computer development. Programmers need to be able to understand what programmers before them were attempting to do; operators need to know what steps, exactly, they are to take when an event occurs; those supporting the application's clients need to have a clue how it works; and those who are going to use it need to know how to use it.

So, starting at the bottom: most programmers do not put descriptive notes in their programs to explain what sections of code are supposed to do. Many of those who do, write non-helpful comments (and this is a true example) like: This code is fucked up. Thanks guys, I really appreciate that helpful advice. So, right away you have a problem.

Joe writes a function that takes the system time in its internal format and extracts and formats the fields the program requires. Of the 128 bits that many computers use to track time, we want to know only the name of the day of the week, for example. Joe leaves the company and Mary discovers that the program needs only the first three letters of the name of the day of the week, so she goes into Joe's function and tinkers with it. Two years later someone thinks that the time of day would be a good thing for the function to fetch as well, so they add their fragments of code to what was already there. Unless these things are done correctly, the program will break--and how do you know how to approach it if there are no comments in the code to guide you? When Mary shortened the name of the day of the week, (probably by simply truncating it), she had left some bytes unused in the calling program (the ones that displayed the rest of the name originally). When the time of day is added, you are now returning much more complicated information to the calling program--and does that program have enough memory reserved to be able to contain the added information? Not likely. And, the way large programs are constructed, the function could be called from anywhere in the program, sometimes layered so deeply in other functions and subroutines that its existence is unknown until the program crashes and someone manages to step through the source code, one line at a time, to locate the problem area.

That should explain to you why programs sometimes fail. Another reason is that no one anticipated the uses to which the program could be put. When I was working in the '80s and '90s banks, and other large institutions, were relying on code sometimes written 15 or 20 years earlier. Over the years as business requirements changed, bits and pieces were spliced into the original code. At some point the limitations of the old code were going to have a problem digesting some of the new data and data formats. Banking networks crash and the economy is put on hold while techies locate the backup tapes so they can restore the system and program to a time when it did work. That is a normal part of the procedure and recovery time and procedures are (should be) included in all plans to upgrade or otherwise change something in the program.

A lot of wasted time and effort could be avoided if the folks writing the original code made an attempt to make it decipherable to the programmers that follow them. But, that would entail writing actual sentences in English and real programmers never RTFM. (That's Read the frigging manual for you non-techies reading this).

I sincerely hope that by now large institutions have bitten the bullet and spent the millions necessary to replace the ancient COBOL programs that were written during the 1970's, and that, as part of the process, they required all those involved in the process to master enough basic English so that they could include helpful information explaining just what the heck they were trying to achieve. (I wouldn't count on an MBA (Master of Business Administration) to have mastered that art yet. They were generally too busy spouting nonsense and spending their inflated salaries to bother with something like learning the basics.)

Of course, I was on the inside of the inside of the system and so didn't always appreciate the 10,000 foot view that MBA's and Vice Presidents of Computer Operations and Development worked in. From that altitude they didn't want to know about a function that could fail and endanger the entire project; technical details like that were too far below the tips of their noses to be able to see and appreciate. (Remember that poor programmer I told you about who was working on the External Affairs COSICS project? Hundreds of million of dollars were riding on his shoulders, but no one was interested enough in the details of what he was doing or knowledgeable enough to be able to rectify the situation.)

BTW, if you are operating under the illusion that decisions involving potential millions of dollars are based on careful analysis, detailed planning, and the expert application of technology, I am sorry, but I will have to burst your bubble. It just doesn't happen that way.