The elevators are not what you think
Here’s a story from my Air Force days.
Back in those days, programming teams were structured very differently. All of the actual business logic and domain knowledge was performed by “system analysts”, who would write down in a document what the program was supposed to do. This document would then be handed to a “coder” whose job was to actually enter the code into the computer (often in the form of punch cards). Because coding was a slow process, it was felt that it was better to let the more expensive resource (the analyst) spend their time analyzing, and the cheaper, more junior resource (the coder) do the grunt work of actually entering the code into the machine.
One young coder was given a task to code a set of functions for controlling elevators. In fact, this was a major project that he ended up working on for several years, adding new control features, new safety checks and fixing bugs.
After a few years went by, he made a remark to his boss that he was a bit puzzled about the elevator project. He could see, examining the code, where there were variables to move the elevator up and down — but where was the code to open and close the elevator doors?
At which point his boss burst out laughing. “You don’t understand,” he said. “These aren’t ‘elevators’ in the sense of a box that people ride up and down in. An ‘elevator’ is control surface on the tail of an airplane — in this case, a B-52 bomber.”
What was shocking about the episode is that the coder had managed to go for years working on this project without knowing anything about the application domain in which his code was being used. No one had bothered to inform him what an ‘elevator’ was in all that time. All they had told him was the algorithms and data he needed to know to write the code — symbols and abstractions.
Now, you might find this story hard to believe. I don’t know for certain that this story is true, but what I can tell you is that something very similar happened to me. My job in the Air Force was to write code that generated reports from a database. Often my instructions would be things like “make sure that the numbers in column seven are the sum of the numbers in columns five and six.” Except that no one ever actually told me what the numbers in those columns represented. It was only after working on this stuff for several years did I learn that those databases represented aircraft maintenance reports.
This story is tragic, because by failing to educate the young coder, they effectively wasted one of their most valuable resources — an intelligent mind that was intimately familiar with the code. Had the coder actually known what the code was for, they might have been able spot bugs or design flaws, serious ones that could have put lives in jeopardy.
While this is an extreme example, things like this still happen today: junior engineers are given instructions from their seniors, and carry out those instructions by rote, without actually understanding the deeper principles which motivates and informs the design.
Obviously, we can’t turn everyone into a senior engineer overnight, but we can try to make sure that when we do delegate to someone with less experience, we also teach them. Every task is also an opportunity for learning and greater understanding. Even under time pressure of tight schedules, we should never lose sight of this.
