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.

Dear Mr. CIO

I recently read of a disturbing trend: nationally, only 1.5% of incoming college freshmen major in Computer Science.  Incredulous, I reached out to a colleague at a local university. He confirmed that, at his institution, the figure was actually less than 1%.  Meanwhile, thousands of software development jobs are shipped overseas, to India and to Russia.

A future crisis is not difficult to imagine:  in a year or two, or five, who will write the code?  And by code I don’t mean the design of web pages or mobile device apps, I mean the business logic that actually drives our business processes (and inhibits them when it’s lacking).

I believe that business users understand their problems, and in most cases understand what’s needed to solve them.  If they also had at their disposal the resources to devise and implement solutions, then many of their problems would be short-lived. I characterize this problem solving activity as Tactical Development, that is, business users building software to address the many short-comings of today’s business systems, short-comings that keep them from realizing their goals.

Tactical Development is already going on to varying degrees in operational departments of businesses across America, and is often critical to the efficacy of business applications.  But business needs more and better tactical developers, and it needs to acknowledge the important role that tactical developers play and to support their efforts.

May I ask, sir, how supportive are you of the tactical developer?  Would you know one if you saw one?

Please consider.

Thanks,

TacDev1

Renegades, rogues and phantoms

During a recent slog through the tech slush pile (also known as a review of the literature), near the end of a rambling stew of corporate group-speak peppered with buzz-words (and oddly labeled ‘Thought Leadership’), I came across the following recommendation made by the CIO of a well known American company:

“If you want to position your organization to use technology to drive business value . . . then create and enforce clear IT policies throughout the organization to prevent adoption and utilization of renegade IT solutions that don’t support corporate IT strategy.”

Ah, yes. The renegade solution. The shadow system. The terms ‘renegade’, ‘rogue’, ‘phantom’ and ‘shadow’ conjure up images of cowboys, of pirates, of covert operatives on secret missions . . . wonderful grist for the Hollywood drama mill . . . but hardly an accurate depiction of the tactical developer.  Tactical Development is interesting and rewarding work, but it’s not nearly as intriguing or romantic as all that. And characterizing it in this way amounts to little more than propaganda.

If the user were fully satisfied with the product delivered by IT, or by its vendor partners, there would be no need for the shadow system or rogue solution, and there would be no need for the business to look elsewhere for answers to its operational problems.

If rogue solutions, purpose-built to solve business problems and entirely consistent with the business agenda, are out of line with IT strategy, then perhaps it’s the IT strategy that’s in need of some alignment.

The simple truth is that every shadow system is a working testament to the unwillingness or inability of IT to deliver. Every single one.

It’s also true that some of the best ideas for utilizing technology to further the business agenda come from the field, and if these gems don’t quite align with the corporate IT strategy, that’s no reason for the business not to pursue them.  They represent potential markets, or operational efficiencies, or opportunities for competitive advantage. The CIO who ignores them, or dismisses them, or actively attempts to ‘prevent their adoption or utilization’, may soon find herself out of the (business) loop.

Congrats to Attachmate

I recently received an email from Jeff Hawn, Chairman and CEO of the Attachmate Group, announcing Attachmate’s acquisition of Novell, Inc. That email caused me to pause and reminisce about my very productive and fruitful days as an Attachmate user.

In those days, we used Attachmate’s terminal emulation software as our primary means of connectivity with our mainframe business applications. That product came equipped with its own built-in scripting tool, a version of VBScript known as ExtraBasic.

Positioned as it was at the point through which most data passed, and at the fingertips of every user on every desktop, ExtraBasic offered considerable strategic and competitive advantage.  It was only a short time before we users realized how to leverage ExtraBasic to capitalize on the data flow.

Although our initial developments were simple macros and shortcuts, we eventually went a little crazy. To take advantage of ExtraBasic’s full COM support, we developed functionally rich DLLs, which together became the basis for full-featured and nearly standalone applications, interfaces with local data bases and lots of automated data entry. And oh, how we had our way!

I know more than a few seasoned tactical developers who cut their coding teeth on ExtraBasic, and proceeded from there to success on many other platforms. And we all came to understand and appreciate the value and the power of having our hands in the code.

Mr. Hawn and the folks at Attachmate are to be commended for putting development tools into the hands of operative users at the point of contact with their applications, and for launching or forwarding the careers of tactical developers everywhere.

From this tactical developer, thanks, and best of fortune in your future endeavors.

The Tactical Developer's Manifesto

The Problem of Incomplete Systems

               Computer software, and in particular business applications, often come up short on the promise to deliver full functionality and operational support to the end user. Whether monolithic stand-alone applications or broad enterprise-wide collections of nominally integrated modules, most suffer from gaps in functionality and control, discontinuities at integration points, partially implemented functions, and unresolved technical and operational issues. They are, from the perspective of the operational user, incomplete.

One Size Fits All

               No system can be all things to all people. Business practices vary among industries, and among enterprises within industries, and even among departments within enterprises, and all for legitimate business reasons. Changing business practices to match system capabilities is often not possible, or seriously conflicts with the business model either philosophically or practically.  The system should not be allowed to, but often does dictate business practice, especially by way of its own limitations.

Conceptual Disunity

               Large scale development is usually modularized along functional lines. The sheer scope and breadth of such projects are at odds with the need for adherence to cohesive design. Separate teams develop in parallel, but not necessarily in synch. Business partners’ products share only a tangential commonality. Only a high degree of discipline can prevent deviation from the conceptual unity of a master plan. Such departures result in the gaps and cracks that are the symptoms of incompleteness.

Sub-optimization

               Faced with an ever-shortening time line and a dwindling budget, a development team will package up any unfinished business and defer it to a future release. Or an implementation team will collect a miscellany of loose ends and call the bundle Phase II.  As a result, operational users are left to their own devices, to invent awkward, quick and dirty, and clerical solutions to system problems.  These work-arounds, intended only to be stop gap measures, often end up as part of standard operating procedure.

The Pursuit of Completeness through Tactical Development

               In a dynamic market economy, gaps in service represent niches to be filled and exploited by enterprising entrepreneurs, but in a business operation, such gaps only undermine efficacy and productivity, especially when there are forces at work that prevent or delay their resolution.

               Through Tactical Development, business users, in the pursuit of completeness and full functionality, design and implement solutions to their systems’ problems. Tactical developers aspire to actualize the system, that is, to close its gaps and realize its potential.  They strive to master the tools of the trade, well enough to leverage and even exploit them. They endeavor to extend the functionality of their systems and tools.  And they pursue each of these goals in the interests of system efficacy, business productivity, customer service and competitive advantage.

Actualization

               Actualization means bringing the system to its full intended purpose; bringing its full force and power to bear on the business problem; having it do all of the work that it was expected (or hoped) to do. Actualization means completing the system and thus maximizing its value and benefits to its operational users.

Mastering the Tools

               Business systems and tools (report writers, query languages, macros, scripts, spreadsheets and data bases) are often not well enough understood to be used to their fullest effect.  It takes a depth of knowledge and insight, a mastery of tools and techniques, to actualize the system, bring it to completeness and use it to full advantage.

Extending Functionality

               While the complete system will perform in the expected way, it may also lend itself to unexpected uses and applications.  Armed with a mastery of tools and techniques, the tactical developer will discover those applications and extend the functionality of the system to unintended but necessary and desirable ends or other creative uses.

Principles of Tactical Development

               The ultimate success of both the business system and its users depends on a commitment to certain core principles: that business practice cannot be confined to, or defined by, system capability; that the system can only reach its potential by continued and sustained development; that continued development of the system depends on the continued development of the skills of the developer; and that the developer and the end user share considerable common ground.

The system should not dictate business practice.

               The system should support the business effort, facilitate business actions and decision making, and even evolve into a competitive advantage for the business. It should also do most of the work and give people what they need to do their jobs. What it should not do is limit options or choices, hamper decision making, inhibit or discourage action or force people to work around it.

Good software evolves.

               The prescription for incompleteness and creeping obsolescence, as well as the means of extending functionality and exploiting fully the potential of a business system, is continuous improvement . . . persistent, incremental and continuous improvement.

               Continuous improvement is synonymous with the pursuit of quality. In fact, when a less-than-optimal solution is the best that can be achieved given the current resources or the current environment (technical, political, operational), it represents a platform from which an assault on a better solution can be launched.  Continuous improvement doesn’t follow a straight line, but it also doesn’t settle.

Practice Makes the Master

               Continuous improvement applies to skills as well as software; skills mature and evolve, too, and not so much by passive training as by active practice.  Writers write, and in doing so hone their skills as writers. So, too, do tactical developers pursue mastery of their tools by cobbling code, experimenting with techniques and building prototype solutions.

               The time when ‘computer literate’ implied a certain set of technical skills is long gone; today, literacy is simply insufficient, as is digital savvy. Fluency and eventual mastery are the means to solve problems and achieve goals, and the pursuit of command of language is an ongoing imperative.

The Closer, the Better

               The essence of tactical development is proximity; it takes place on the front lines, where application meets operation. The closer to the customer that development takes place, the more likely it will be guided by the business agenda, which is often informed by a higher authority (like fiduciary responsibility) or superior principles (such as GAAP). And, of course, motivation to solve the problem is highest close to the customer.

               Business users understand their problems, and in most cases understand what’s needed to solve them.  If they also had at their disposal the resources to devise and implement solutions, then the problems would be short-lived. Tactical development aims to bring the degree of separation between the person with the problem and the person with the solution down to zero or one. Ideally, the understanding of the problem and mastery of the tools to solve it reside in the same head, that is, the head of the tactical developer.

On Being a Tactical Developer

Successful tactical developers . . .

. . . have a bias for action. They resist excuses, take the initiative, and invest themselves.

. . . resist sub-optimization.  They don’t allow good to become good enough, or, if good enough is all that is possible today, adopt a policy of continuous improvement, and make it better tomorrow.

. . . bring their own tools and skills to the table. They seek mastery, and invest in themselves to attain it.

. . . are their own best customers; it is their self-interest, the fountainhead of progress, that motivated them to take on tactical development in the first place.

. . . don’t lose sight of their operational responsibility and accountability, often answering to a higher authority.

. . . don’t dismiss tried and true techniques and tools, realizing that sometimes the best understood and most effective solutions come from trailing edge technologies.

. . .are self-reliant. They know that in certain circumstances, one well-armed, well-trained and highly motivated individual can be more effective than an entire army.

… prefer the surgical solution to the overhaul, and the deftly placed modification to the Angus MacGyver workaround. They know that tools are not to be used haphazardly or indiscriminately, but thoughtfully, judiciously and in line with the conceptual design and structural integrity of both the system and the business model.

. . .are fault tolerant. Mistakes are barely tolerable, but making them is inevitable, especially during exploration, experimentation, development and prototyping, all of which lead to the discovery of solutions and new uses for existing tools. 

. . . are self-aware. They know that every system and tool imposes its own paradigm, and don’t get so caught up in them as to lose perspective or objectivity. They are the masters of tools, not slaves to them.

. . . take the high road. They know that there is little to be gained from criticizing the system, or antagonizing the people who sold it, installed it or run it.  They acknowledge that, although it is incomplete, the system still does 90 or 95 or 99% of the work.  They opt to use their powers to push, pull or coax the system closer to actualization, and for the benefit of all. 

Salutation

               If you’ve been in the trenches for a while and have the hard won knowledge to prove it, congratulations, you’ve earned the title.   If you’re new to tactical development, welcome, an adventure awaits you. Either way, trust your own judgment and have faith in your ability to solve the problem.  Your technical skills are the tools with which you can carve out your destiny.

Signed,

TacDev1