1. A piece of code, not yet written, whose anticipated length is significantly greater than its complexity. Used to refer to a program that could obviously be written, but is not worth the trouble. Also used ironically to imply that a difficult problem can be easily solved because a program can be written to do it; the irony is that it is very clear that writing such a program will be a great deal of work. “It's easy to enhance a FORTRAN compiler to compile COBOL as well; it's just a SMOP.”
2. Often used ironically by the intended victim when a suggestion for a program is made which seems easy to the suggester, but is obviously (to the victim) a lot of work.
True story, not even a tiny bit exaggerated:
Back when I got my first captive job as a product development engineer (age 29) I went to work for a large medical systems company whose name rhymes with Siemens. I worked on a nuclear medical imaging product with a name rhyming with KONTRAST. This device was being developed under the "stooper-vision" of a manager we'll call Tony, because that was his name. Tony hated software and the people who created software. I was made aware of this fact by another captive under Tony's stooper-vision, who regaled me with the tale I relate now.
The reason for Tony's software loathing was a failed digital imaging station project under Tony's "care" that had floundered before I joined the company. It seems that a team of hardware engineers -- "sparkies" or "rods," to you folk keeping track of such things -- had worked for nearly two years putting together the hardware design for this imaging station before management (read, "Tony") even thought about adding some software engineers -- "cones" or "mushheads" -- to the mix. The reason for this? "Well, the electronics are all worked out, so the hard part is done. Now it's just a simple matter of software." This is a direct quote.
Needless to say, this imager project was a complete disaster. After some man-years' worth of labor in trying to create software that would make this abortion run the higher-ups decided to drop the whole thing. Tony was relegated to the far northeast corner of the Des Plaines building, next to the railroad tracks. It was literally the farthest distance away from the corporate offices he and his greatly reduced staff could be placed and still be in the same zip code.
I was brought in some time later on Yet Another Hardware Product Needing Software. Apparently Tony didn't learn his lesson the first time around, because the KONTRAST hardware had been designed by people who had apparently never written a line of code in their lives. Just the way the interrupts were configured was evidence of that. Nonetheless, after two years of solid work I got KONTRAST ready for market.
Then I got out of Siemens just as quickly as my little footsies could carry me. Tony was absolutely the worst boss I've ever had, bar none. A big part of this was his contempt for anyone having anything to do with software development, despite the fact that six of the eight projects under his direction were much more software than hardware. Even the GAL photon count processing hardware in KONTRAST were microcode based.
Oh, well. One learns how to avoid such situations. And these days we have TheConsultantsMantra
to cover those situations where such idiots are unavoidable.