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
No comments:
Post a Comment