What Lessons Can An Old Typewriter Teach Us?
It was a bright sunny afternoon in early January, the sun was shining in a blue sky with just the occasional puffy white cloud, the temperature was in the mid 70’s and all was well in my little world. I was on a back road to a little airstrip from which I like to fly listening to the radio as is my wont and they were talking amiable non-sense about art in the work place made from paperclips and post-it notes. One of the studio guests was commenting on the sound of a “real” typewriter that had been in a previous report and how that brought back memories of times gone by and the smell of carbon paper that they had used to make copies of typed memos before the age of the photocopier. She spoke about the difficulty in correcting mistakes made on the typewriter because although they had a “state of the art” IBM model that could “lift” the incorrect type from the page with a single button press, it would not correct the copy on the carbon paper below. This they would “painstakingly” fix with correction fluid – liquid paper that would cover the mistake and allow them to write the correct letter in place of the one that had been mistyped.
My mind lingered on this long after the panel had moved on to more interesting subjects such as the “little boy in the candy store” feeling when standing alone in the office supply room…I remembered doing this myself (correcting mistakes on a typewriter that is, not standing in awe at the sight of neatly arranged stacks of notebooks and pens). It occurred to me that we did make mistakes - it felt like we made a lot of them at the time because of the huge effort needed to correct each one - but I remember a “mistake” was typing the wrong letter, hardly ever the wrong word. I pondered next the fact that when typing up an article even as short as this I delete whole sentences, sometimes even paragraphs at a time and what would we do with out that little squiggly red line that appears ever too frequently to show us just how bad our spelling has become.
The reason, I postulated, was the lack of planning for each such authoring event, combined with the lack of training in the correct methods (such as grammar and spelling). To be fair now the fact that the typing pool could type up memos so fast and so accurately was in part because they were typing up a hand-written note prepared for them by someone who had already structured the content for them; now in the age when every one at every level has their own “typewriter” these two actions are combined. This in turn leads to much larger corrections, some not “mistakes” in the classic sense but rather word choices that are later revised. The number of crossings out and rewordings on those hand written memos attests to this without knowing how many copies hit the trash before ever making it to the typing pool. Even so the thought occurs that a difference has been made here and we should at least question if it is entirely for the positive. Why should it matter that the medium for final deliverable and the intermediate scratch pad on which our thoughts are incubated have been combined? Perhaps it matters because the scratty hand written note would never have been delivered to the world of paying customers, or bosses or employees, it would have been typed up and then reviewed before being blessed for dissemination to its intended audience. Just how much review and preening is built into the system now that thought and action have been combined into a single operation?
By now many of you are wondering why I am driveling on about life in the typing pool some 20 years ago vs. the “modern” age of word processing software on each desk. The point is this…we have done a wonderful thing in lowering the cost of mistakes. No longer must we manually correct each letter mistyped, painstakingly examine each word for spelling mistakes, and risk the complete re-work of the entire page if a larger mistake has been made with only the hope that it will be done correctly the second time. In so doing, we have made mistakes more tolerable and lowered the barrier of entry for those who wish to be able to produce such neatly typed output, but what have we lost in the bargain?
By no longer requiring people to have to know how to spell each and every word, we have lowered the effort that they put into learning (ask yourself how many times you type the same word wrong the same way these days, even though your desktop application brings it to your attention each and every time). By allowing editing “on the fly” with little or no penalty, we have encouraged the writing of documents whose structure is not thought out in advance and the result is often not the clarity of reading we might otherwise hope for. By correcting spelling on the fly we have encouraged the lack of proof reading that would catch correctly spelled but incorrectly “sensed” words that change the whole meaning of text that we have written.
This phenomenon is not restricted typing the written word. It plagues us in software development too. We have done much to lower the cost of mistakes. We have made it easier for very laudable reasons. We have created new languages that encapsulate complex ideas and abstract them away into the plumbing. We encourage prototyping to develop new ideas in order to quickly “see” the product, to better shape it to real needs. We design our architectures for maximum flexibility in post developmental reconfiguration …SOA could be said to be the state of the art in that matter. A well design Service Oriented system can be reconfigured on the fly to meet changing needs. Ergo, if the needs in the minds of the system implementers are in fact completely different from the needs in reality we can leverage this flexibility to accommodate the difference (to undo the mistake). Does this mean that there is no value in the Software Engineering principles that we used to rely on when we couldn’t afford to fix mistakes later? Hardly!
I think about how tempting it is even for such a “dinosaur” as me to forget all about rigors of software design as I was taught them so long ago… It seems so much easier to leap in to code, build some “prototype” screens in the editor and by mid-afternoon have a “working” system. We can change the badly thought out bits later, we probably never will though… Many of my colleagues have also lived through the development of Software Engineering through the past quarter century and more; though none of us are immune to the skills atrophy process, at least we were taught how to use process, planning and forethought to avoid the mistakes in the first place. Some of us are so old that we “desk checked” every line of code before ever running the compiler because computer time was so much more expensive than human time. The result was that tremendous amounts of thought and planning when into our work. What of the younger generation? Much as the mathematics skills of the school kids of today has been found somewhat lacking because of the ubiquitous nature of the calculator, are we building a pit for the next generation of “Software Engineers” to fall into?
What am I suggesting? That we should forget about Prototyping and Service Orientation? Dismiss “Managed” languages as heresy? Go back to the waterfall method of building monolithic code, but do it carefully? Abandon our Word Processors and recreate the old typing pools? Smash the Spinning Jennies? Luddites of the world unite! No, I think not; instead I believe that we should be grateful for the tools that allow us recover from mistakes more cheaply but that we should fight continuously against the natural tendency that such tools have to atrophy the skills we used to use to avoid those mistakes in the first place. Use the tools we have to augment the skills we have, not to replace them. The new tools can make us so much more productive, allow us to deliver so much more quickly, but we must never allow them to be used as a substitute for thinking the problem through.
Comments
- Anonymous
January 11, 2005
The comment has been removed