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.

It's Never Too Late . . .

Let’s say a system fix or enhancement is estimated to take from six months to one year to implement (that is, starting from the point in time when resources become available). Or a vendor has agreed to include a fix in some future release.  What’s a nothus miserum to do in the meantime? Muddle through manually? Cobble together some clerical work around?

When a tactical developer implements a solution, it is often with the intention of phasing out the tactical solution when the ‘real’ solution becomes available; that is, when the vendor has finally included the fix or feature, or when the request is eventually plucked from the IT job jar.

As often as not, and certainly too often, the development of the ‘real’ solution never gains legs, or meets with technical or political obstacles, or budget cuts, or shifting priorities, or simply the inability of IT to finish the last ten percent of the project, so that the tactical solution is eventually absorbed into the standard operating practice of the business. Over time, the operating terrain can become littered with tactical solutions, to the dismay of IT management, under whose watch the proliferation proceeded.

But take heart, Mr. CIO, for it’s never too late to assimilate tactical solutions into the mainstream system. Rather than shunning tactical solutions and their developers as the illegal aliens of the business application world, please consider adopting a policy of inclusion by providing them a path to integration.

This path may include refactoring some code, redesigning a few components, or adjusting at a few points of interface. Yet, the tactical developer will have already done the hard parts – working out the fine points of the users’ requirements, articulating the code, and providing you with the perfect model for the ‘real’ solution.  In fact, the hardest part of assimilation may be acknowledging the tactical solution at all (that is, admitting that some of the best ideas come from the field). But after all, savvy managers know that solutions are where you find them.

The benefits of tactical solutions need not be revisited here.  You can simply ask the man who owns one. But the benefits of assimilating them go beyond IT control and standardization.  The user community in general and the tactical developer in particular will exhibit a greater affinity toward the application, having had an active hand in its development and improvement. And, because the problem and its solution are well defined and well understood, the task of assimilation will not require a commitment of your top talent, and may offer the younger or newer developer an opportunity to work with the tactical developer, learn a bit about the business, take a tactical solution off-line and bring a short-term, low risk, high value project to completion.

Good software evolves. And with a little guidance, over time, incongruities can be resolved, standards can be met, and good business solutions can become good IT solutions as well. Sound like a plan?

New clubs, new course?

Two of the most valuable assets in a legacy system are the depth of understanding of the domain (the applications and their files, behaviors and quirks) and the mastery of skills using the associated tools that have accrued to their practitioners over time.

Loss of this knowledge and these skills are also two of the most underestimated costs of converting to a new system. Often, the level of skill needed to complete the transition cannot be attained within the time frame allowed for the conversion. That means that some of the problems and issues encountered during the implementation of the new system will be only partially solved, or not at all.

Consider the golfer who, with his old clubs and on his home course, can play at or close to par. Acquiring new clubs can present a short term setback. Time is required to accustom oneself to the idiosyncrasies of new ‘tools’, their weight, balance and action.

Consider further the golfer who is invited to play at a new, unfamiliar and difficult course. Should he take his old clubs or his new ones? Does he prefer to impress with his equipment or with his game?

If he believes his playmates will be impressed with what’s in his bag, and he doesn’t mind shooting 92, he should take the new clubs.  But if his game matters (and in business, it certainly should), then his old clubs may serve better. He can always make an excuse about the old clubs (the new ones are in the shop being polished), but is unlikely to get away with blaming a poor performance (as might any poor workman) on his new tools.

Legacy tools, and any trailing edge technologies, retain their value because of the seasoned professional hands in which they find themselves. The leader who insists that the new course be charted using only new tools increases the degree of difficulty of the task at hand, and hampers those charged with its completion. He also places his resources in the difficult position of having to use old tools surreptitiously.

An unenlightened leader may go as far as to characterize legacy tools as crutches, and their use as a symptom of fear or unwillingness to change.  The tactical developer (as well as the enlightened leader) is more concerned with performance than appearance, and knows well that chances of success improve dramatically when he undertakes a mission with both old and new tools at his disposal.

In the transition to a new system, the value of legacy domain expertise may be lost, but the skills in the use of legacy tools can serve deep into post-production, and can even be the ‘secret’ weapon that helps pave the way to success. Of course, this is no secret to the tactical developer.

Rethinking the Talent Search

In a recent article in CIO Magazine (May 1, 2011), Kristen Lamoreaux, president and CEO of Lamoreaux Search, echoes the sentiments of the inimitable French Prime Minister Georges Clemenceau by suggesting that hiring and retention are too important to be left to HR.  She calls CIOs to action, recommending that they take the lead and get creative by cross-training existing employees, revitalizing employee referral programs, and sponsoring innovation contests, all with an eye toward keeping employees engaged and excited, and having a great recruiting story.

Ms. Lamoreaux does not suggest that the CIOs take matters into their own hands, but rather that they work in concert with HR toward a common goal. Yet among her many valuable points, she may have omitted an important and worthy consideration:

Outsourcing does not have to mean outside the country, or outside the company. It may simply mean outside of IT. And ‘existing employees’ doesn’t have to mean existing IT employees, particularly when it comes to application development. After all, some of the sharpest development resources in the organization do not work in IT.

Tactical developers bring valuable resources and motivation to the table. Their domain expertise, business knowledge and coding and problem-solving skills make them ideal candidates, not for recruiting so much as for inclusion. How? By lending some support to their efforts, by making technical training available, by granting a bit of access, by offering a seat at the applications discussion table, and by allowing them a little room to maneuver, the enlightened CIO can integrate tactical developers into the development cycle.

An enormous amount of added value stands to be gained, not just to the efficacy and useful lives of the applications themselves, but to the business ownership of an essential factor of production as well as to the IT-business partnership.

A business side manager who has realized the benefits of tactical development might echo both Lamoreaux and Clemenceau and say that application development, particularly tactical development, is much too important to be left to IT.