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.