Every once and a while I have to remind myself of my roots in the Information Systems world. In an Internet discussion group I monitor, a young programmer recently lamented his department spent an inordinate amount of time in "maintenance" and not new development. I do not believe this is what he meant to say but it reflects some common misconceptions about systems and programming.
Within any systems development organization, there are but three types of work effort: new systems development, maintenance, and modification/improvements. A mature development organization will spend approximately 5% of its time on new development, 10% on maintenance, and 85% of its time on modification/improvements. Let me be clear on our terminology; maintenance is nothing more than the correction of defects, making the system operate in accordance with the specifications of its design. However, the lion's share of work is in modification/improvements (mod/imps) which represents changes and enhancements to existing systems. There is a good reason for this; very few companies live in a stagnant world, their information requirements are constantly changing due to such things as competition, economics, government regulation, mergers, acquisitions, diversifications, etc. The fact is, business lives in a world of constant change. Change is natural. In addition to changing information requirements, our technology is evolving. For example, software that operates on one computer, will not necessary behave the same on another, hence the need to modify it. The same is true to changes in operating systems and third party packages requiring upgrades from one version to another, thereby affecting in-house programs. The point is, systems and software people live and work in a world of change, not maintenance.
Knowing this, what can be done to accommodate design changes? Several things actually:
* Design system components to be reusable. Decomposing software into reusable building blocks is certainly not a new concept, but to do so requires certain organizational skills and discipline to make it happen. Sharing has to be built into the system component from the beginning, not added in later on. This means design standards have to be invented and reviews enacted to assure compliance. In addition, a repository to inventory and cross-reference such components also offers tremendous leverage to developers and promotes sharing and reusability.
The only alternative to the building block approach is to rewrite programs in their entirety. I have seen both scenarios played out in business. The building block approach is a more cost effective approach that can save considerable development time and money but, as mentioned, it requires organization and discipline in order to properly implement.
* Embrace standards. Uniformity in design means the development staff operates at a common level and shares a vocabulary which obviously improves productivity and simplifies both maintenance and mod/imps. If done properly, a systems analyst or programmer should be able to quickly understand what another developer has done and implement the necessary change quickly. As in the building block concept, design standards have to be adopted and enforced. Without enforcement, there is little point in formulating any standard.
Consideration should also be given to standard design processes so developers fully understand who is suppose to do what, when, where, why, and how. This of course means the use of standard methodologies which provides a road map for development work.
* Logical/physical design. Systems should be designed in such as way as to create independence from the physical environment which is prone to change. Since systems can be implemented physically many different ways, why not design them logically thereby simplifying technological implementation?
For more information on this concept, see my earlier paper entitled, "Logical vs. Physical Design: Do You Know the Difference?"
* Implement new tools to expedite development.
Since the bulk of a system development organization's efforts are in modification/improvements it would make sense that management devise a means to expedite such work effort. Developers can either continue to rewrite systems and software, thereby consuming considerable time and expense, or they adopt some rather simple techniques that can greatly streamline their affairs. It ultimately depends on management's willingness to implement organization and discipline in their department. Bottom-line, does management perceive systems development as a science or an art-form? If the former, yes, they can adopt such changes. If the latter, no, nothing will change and developers will continue to lament they are doing nothing more than operating in a maintenance mode.
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Tim Bryce is a writer and the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at [email protected]
For Tim's columns, see: http://www.phmainstreet.com/timbryce.htm
Copyright © 2010 by Tim Bryce. All rights reserved.