Tactical Dictionary: misonothy

mi•so•no•thy (mĭ-sŏ̕nō-thē) noun. Hatred, contempt or disregard for poor bastards

Etymology: from the Greek miseo, meaning “I hate”, and nothos, meaning “bastard”.

Synonymns: misonothism

Antonymns: philonothy

Derived terms:

misonothist

               - noun. A person who hates the poor bastards, or holds them in contempt or disregard

               - adj. Characterized by hatred, contempt or disregard for the poor bastards

Tactical Dictionary: Nothus Miserum

Nothus Miserum is a Latin phrase, from nothus meaning ‘bastard’ and miserum meaning ‘miserable or poor’, and translates to the English phrase ‘poor bastard’.

The term ‘poor bastard’ generally refers to someone who finds himself in an undesirable situation or difficult circumstance, or who suffers from the indignities of some misfortune. It is usually used with a sympathetic, and occasionally with a humorous tone.

The term ‘nothus miserum’ refers specifically (and euphemistically) to someone who relies on computer software to perform work or conduct business, and is hampered by the effects of the developers’ poor design choices or shoddy workmanship, or by short cuts taken during development.

This poor bastard is forced to compensate with onerous manual work and awkward workarounds, none of which would be necessary had the software been developed properly.

Cinematic references to ‘poor bastard’:

From Steven Spielberg’s Saving Private Ryan (1998)

Private Richard Reiben (Ed Burns): "You wanna explain the math of this to me? I mean where's the sense in risking the lives of the eight of us to save one guy?"
Captain John H. Miller (Tom Hanks): "Anybody want to answer that?"
Medic Irwin Wade (Giovanni Ribisi): "Reiben, think about the poor bastard's mother."

George Kennedy, as Ben Bowman in The Eiger Sanction (1975):

“She's a regular mantrap. I feel sorry for the poor bastard trying to keep his eyes on her.”

George C. Scott, as General George Patton in Patton (1970): “Now, I want you to remember that no bastard ever won a war by dying for his country. He won it by making the other poor dumb bastard die for his country.”

Leslie Nielsen, as Dr. Rumack in Airplane! (1980): “At this point, the entire digestive system is rendered useless, causing the complete collapse of the lower bowels, accompanied by uncontrollable flatulence, until finally the poor bastard is reduced to a quivering, wasted piece of jelly.”

Literary references to ‘poor bastard':

John Steinbeck, The Grapes of Wrath: "Floyd said, `Twicet now I've fell for that. Maybe he needs a thousan' men. He'll get five thousan' there, an' he'll pay fifteen cents an hour. An' you poor bastards'll have to take it `cause you'll be hungry. `"

George Orwell, Coming Up for Air: “But in every one of those stucco boxes there’s some poor bastard who’s never free except when he’s fast asleep and dreaming that he’s got the boss down the bottom of a well and is bunging lumps of coal at him.”

J. D. Salinger, The Catcher in the Rye: “If you want to know the truth, the guy I like best in the Bible, next to Jesus, was that lunatic and all, that lived in the tombs and kept cutting himself with stones. I like him ten times as much as the Disciples, that poor bastard.”

Other uses of ‘poor bastard’:

General Creighton William Abrams, Jr. (1914-1974), during WWIIs Battle of the Bulge: “They’ve got us surrounded again, the poor bastards.”

Same Old Song

In a recent issue of CIO Magazine (September 15, 2011), the cover story was dedicated to the subject of “Rogue IT”, and featured a side bar titled “Taming the Rogue Element”.  In that side bar, several CIOs were quoted as follows:

“the customer is not aware of what the business owns . . .”

“they don’t give IT a chance . . .”

“they’re not following a strategic plan . . .”

“they don’t communicate their needs . . .”

“users don’t know what they want . . .”

“they do not know where to start . . .”

Anything else?  How about: they’re lazy, they’re stupid, and, oh yes, they’re ugly too!

Although I can hardly believe that these statements reveal prevailing attitudes among today’s CIOs, I do wonder how these attitudes make their way to the top, and how they are perpetuated.

One might guess that such prejudices are bred in IT schools, the way some believe medical schools teach arrogance, or seminaries teach pomposity. But this would amount to little more than counter-productive counter-prejudice.  And, having attended IT school myself, I know that not to be the case.

Perhaps it’s part of an indoctrination process.  Do aspiring CIOs have to memorize the misonothist mantra in order to be accepted into the club? If so, then I would expect media savvy executives at least to mask their disdain for their customers, especially when they’re about to be quoted in a trade publication. Clearly, these Cs were not among the savvy.

Then again, perhaps it’s this kind of article that spreads the corporate groupspeak. If so, then maybe it’s time for IT journalists to realize that they need not print every word their subjects utter.  That, or start interviewing a more enlightened class of CIO.

On Technical Debt

I recently had the opportunity to attend an on-line seminar conducted by none other than the venerable Steve McConnell, CEO and Chief Software Engineer at Construx Software. As a long-time admirer of Mr. McConnell’s work (Code Complete), I could not pass up a chance to hear him speak.

His topic was "Managing Technical Debt", referring to the software development costs associated with delayed technical work when short cuts are taken, or when planned features are eliminated or deferred, or when the short term expediency of low quality technical work is deemed acceptable.

As Fred Brooks (the much admired author of The Mythical Man-Month) observed many years ago: “On large teams, sub-teams tend to sub-optimize to meet their own targets rather than think about the total effect on the user. This breakdown in orientation is a major hazard of large projects.”  Mr. Brooks may have seen technical debt as a direct result of sub-optimization, and would certainly have included the ‘total effect on the user’ as part of the cost of assuming and carrying the debt.

As Mr. McConnell explained, in order for suboptimization to result in technical debt, it must entail some kind of expense or cost, and he suggested further that, if there is no cost associated with suboptimization, then it’s really not debt at all, and encouraged the listener to take on ‘zero interest’ debt, or debt with very low interest, or debt that need never be repaid.

At this point the entire concept of suboptimization as debt flirts with a dangerous rationalization that can be brutally costly to business operations; that is, the ’major hazard’ referred to by Mr. Brooks.

Simply put: there’s a big difference between a debt having no cost and having no cost to you. Can there be any incentive for the indebted to retire their debts, or any disincentive against taking on debts, if someone else is footing the interest bill?

I have heard it said many times: “IT made a bad decision years ago, and we’re still paying for it.” The users, who expected to accrue certain value from those deferred features or those suboptimized levels of function, will have to continue to operate at suboptimal levels, or worse, have to compensate by developing alternative methods, workarounds, or tactical solutions.  Forgone benefits can easily translate into ongoing costs, essentially the service on the technical debt, borne by the nothus miserum who is saddled with effects of someone else’s poor choice.

Mr. McConnell went on to suggest that, when a system is retired or replaced, any technical debt associated with it goes away as well. But, has the debt really gone if the debt service persists? Unless the new system eliminates the need for the manual workarounds and shadow systems that were build and maintained to compensate for suboptimization in the old, then those costs will continue long after the old system is gone.

The debt metaphor is a useful illustration, but the illusion of interest-free credit is a dangerous and potentially costly rationalization. The decision to suboptimize, and to take on technical debt, should be made with the 'total effect on the user' in full view.