According to last month's reader survey, most of you weren't even alive when today's story took place. But Mark Lutton was: the year was 1971 and Mark worked as a programmer in a data processing company.

I'm always amazed at how similar things were back in the 70's. Some companies even offered "performance enhancement" upgrades as they might today. Mark recalls all that was required to nearly double the performance of the IBM 407 Accounting Machine: a sum of money, a technician visit, and a single wire being snipped from the control panel.

It was also just as easy to become The Leech of the programming team. You know who I'm talking about. The Leeches go by many names and been featured here as the "Brillant" Paula, the Abstract Mark, and, in this case, Albert, the De-Compiler.

Being that he was The Leech, none of the other programmers really liked Albert. And of course, there was little they could do about it. Though the quality of his work was atrocious (that is, if he actually managed to produced anything), Albert always was able to latch on to some one else's project just at the last minute and share in its success.

If all that Albert did was ride someone else's coattails to success, we really wouldn't have a story, just yet another example of how so many people find success. When Albert came aboard a project, he tried his darnedest to contribute. Even the most basic of tasks, such as checking some code into source control, would undoubtedly lead to some failure down the road.

Wait a minute, you may be thinking, they didn't have source control back in 1971! Oh, did they ever; it was just a bit different than today's source control. Before sharing Albert's "final straw," here's a quick primer on what coding was like only thirty years ago:

  • The Development Environment consisted of a pad of special paper and a pencil.
  • The Language -- COBOL -- was optimized for paper. In fact, even to this day we haven't come with a more verbose way of assigning variables: MOVE NAME IN INPUT-RECORD TO NAME IN OUTPUT-RECORD.
  • Punching was required after the code was reviewed. Like going to "File -> Save", this process involved handing your sheets of paper to the Punch Card Girls and getting a deck of punch cards back. And I believe that was their official title back then, too.
  • Compiling the punch cards was also required. Like today, this involved putting the source code deck into the compiler and getting an object deck of compiled code back.
  • Testing could only be done on weekends. In today's dollars, an hour of computing time sold for eleventy billion dollars, so the computer (a room-sized mainframe that also sold for eleventy billion dollars) was utilized weekdays around the clock. To test their code, programmers would book time on the mainframe and come in over the weekend.
  • And finally, Source Control was managed using a large filing cabinet. When changes needed to be made to a program, the source deck would be checked-out (they used a clipboard attached to the cabinet), duplicated, recompiled, and both versions would be put back in the cabinet. If the object deck were ever lost or damage, it could simply be recompiled by going to source control.

Ahh, the good ole' days! But let's get back to Albert, who at this point, had gotten himself in a bit of a bind. You see, Albert was tasked with making a small change to the withholding rules on a payroll program. This wouldn't be a big deal for most programmers, except for the fact that Albert managed to lose the source deck. He knew that this was a bad thing, but he had a plan to make things right.

Albert booked several hours of time over the weekend. He figured that, since the compiler "knows" both COBOL and IBM/370 Machine Code, there's probably be some switch he could use to have the compiler produce a COBOL source deck from a Machine Code object deck.

What sounded good in Albert's mind didn't work out so well in reality. It turns out that placing an object deck in the compiler caused the mainframe to grind to a halt and flash lots of warning lights. Normally, the card reader processed 1,000 cards per minute. Albert was able to slow it down to one every two minutes.

Because this halted all testing and debugging for the day, the manager was called in to find out why. When Albert explained that he had lost the source deck and was "just now getting it back by compiling the object deck," it finally "clicked" that Albert wasn't quite the expert programmer he claimed to be. The following Friday -- Albert's last day -- marked a day of celebration in the programming department for many years to come.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!