|
One of the great things about this trade is that we love cryptic abbreviations that we can use to exclude outsiders. I do not mean the purely technical, cryptic abbreviations, but the little bits of slang that add flavor to conversations. For example, everyone knows "GIGO," which means either "garbage in, garbage out" or "garbage in, gospel out," depending on the circumstances.
I use "Foobar" for a SQL table name when people asking for my help fail to provide me with DDL for their problem. Foobar was originally "FUBAR" in the military and stood for "F***ed up beyond all recognition," which is generally the situation when you cannot produce a clear specification for your problem.
But one I have not seen used lately is "SMOP," which means "simple matter of programming." It was a nontechnical manager's reply to the customer when asked, "Can you make it speak Flemish and Urdu, too?" It is amazing how much you can achieve when you don't have to do the real work yourself.
One reason that SMOP has gone by the wayside (along with hot pants and hip huggers) is that programmers today really believe they can whip up a program modification on demand by playing with some class libraries and doing a bit of object-oriented (OO) magic on the fly. In the old days, we knew it was hard to add a feature because we had to worry about storage and execution speed. And, let's be honest, programming languages did not support reuse like they do today.
However, Michael M. Gorman (mmgorman@wiscorp.com), best known for being the secretary for the NCITS H2 Database Standards committee ever since they invented dirt, sent out a classic example of the pitfalls of code reuse in a clipping from Melbourne, Australia ("Defense Science and Technology Organization Lecture Series," June 15,1999).
"The reuse of some object-oriented code has caused tactical headaches for Australia's armed forces. As virtual reality simulators assume larger roles in helicopter combat training, programmers have gone to great lengths to increase the realism of their scenarios, including detailed landscapes and, in the case of the Northern Territory's Operation Phoenix, herds of kangaroos (since disturbed animals might well give away a helicopter's position). The head of the Defense Science and Technology Organization's Land Operations/Simulation division reportedly instructed developers to model the local marsupials' movements and reactions to helicopters. Being efficient programmers, they just re-appropriated some code originally used to model infantry detachment reactions under the same stimuli, changed the mapped icon from a soldier to a kangaroo, and increased the figures' speed of movement.
Eager to demonstrate their flying skills for some visiting American pilots, the hotshot Aussies 'buzzed' the virtual kangaroos in low flight during a simulation. The kangaroos scattered, as predicted, and the visiting Americans nodded appreciatively ... then did a double-take as the kangaroos reappeared from behind a hill and launched a barrage of Stinger missiles at the hapless helicopter. (Apparently the programmers had forgotten to remove that part of the infantry coding.)
The lesson? Objects are defined with certain attributes, and any new object defined in terms of an old one inherits all the attributes. The embarrassed programmers had learned to be careful when reusing object-oriented code, and the Yanks left with a newfound respect for Australian wildlife. Simulator supervisors report that pilots from that point onward have strictly avoided kangaroos, "just as they were meant to."
No system is idiot proof; the best you can hope for is idiot retardant. When the structured programming revolution began, clear, formal specifications were emphasized. This approach does not get mentioned much anymore, and that is too bad.
James Whistler, the artist best known for his painting Arrangement in Grey and Black: Portrait of the Painter's Mother (commonly called Whistler's Mother, 1871), went to West Point in his youth. One of his engineering class assignments was to draw a bridge. Being an artist, he put two small boys fishing off the bridge in his assignment. His instructor, being a proper military type, told him to take the boys off the bridge. Whistler redrew the boys fishing on the riverbank under the bridge. The instructor then changed the specs to "Get rid of those two damn boys!" to be sure that the goal was clear. Whistler then redrew the assignment to show two small graves on the riverbank. And he was kicked out of West Point.
Clear specifications are important, and if you work from them, you might actually have a SMOP on your hands. But don't be surprised when some programmer finds a way around it.
Joe Celko (www.celko.com or 71062.1056@compuserve.com) works at Trilogy Software and his opinions are not necessarily those of his employers. He is the author of Instant SQL Programming (Wrox Press, 1997) and Joe Celko's SQL for Smarties: Advanced SQL Programming (Morgan Kaufmann Publishers, 1999).
|
|
|
|
|