Maintenance, often turned support, is a crucial activity for linking the experiences of users/customers with the product delivery organization. We consider perspectives on high tech maintenance from bug fixing through to design focused activities.
THE CHALLENGES OF MAINTENANCE
Both soft and physical goods need to be maintained over their economic lifetimes, and the time spent is maintenance is many multiples of the time spent in initial development. It also turns out that usability and scope, which are a key drivers of customer value and usefulness for software (1998, Varian et al., 2004), also drives the generation of multiple versions. A single product codebase can be used to generate multiple versions of the same underlying architecture for the same release date. Adding new features, perfecting and adapting the product continuously increases the scope of a product. In addition the work of maintaining the software also generates new products, subsequent versions and revisions incorporating new capabilities, fixes etc (Figure below). Multiple versions are inevitable, they're part-and-parcel of software, an inherent potential and inevitable consequence of releasing applications based on changing code.
Figure: SDLC as interrelated activities
If we look at Eason’s depiction of an idealized systems development process we can imagine both the user and the technology co-evolving over time as learning is acquired from one and the other. Eason’s hypothesizes that users (and therefore organizations) learn, but they also teach developers how the technology system may evolve over time.
“The exploitation of information technology requires a major form of organizational and individual learning… The exploitation of the capabilities of information technology can only be achieved by a progressive, planned form of evolutionary growth.” (Eason, 1988)The evolutionary development of systems grows, from limited basic functionality towards more sophisticated and capable systems over time. Consequently maintenance tools and maintenance thinking has begun to permeate throughout the whole product experience.
Designed change (even for corrective work) is a change to the product, and so the economic assumption that a delivered software product is a finished good is false. The practical reality guarantees that a high tech system will inevitably undergo further change. (Swanson, 1976; Swanson, 1989; Poole et al., 2001) High tech systems undergoing maintenance are often regarded as a ‘mutable mobile’, technology that evolves and changes in use (Law & Singleton, 2005) the idiom of maintenance is employed even though software does not wear out or degrade. Maintenance work is difficult and messy; patches must satisfy new demands without breaking existing installations and work as before (only better).
One aspect of maintenance work that is generally held by programmers is that it is better for your career to work on next generation technology, rather than being stuck on bug fixing or maintaining old versions within the straight jacket constraints of compatibility and legacy codebases (Ó Riain, 2000). Maintenance jobs are therefore often outsourced to low cost locations or shunted into the background noise of the workplace, and so developers often shun the work of maintaining a venerable ‘old version’ as they jockey for assignment to new product projects.
ORGANISING DELIVERY AND MAINTENANCE
Eason (Eason, 1988) describes five main implementation strategies for delivery/deployment, graded according to how radically the system changes (Figure below). From revolution to evolutionary change, imposing likewise a burden on the user to adapt, from difficult to easy. Leonard-Barton (1988) described this same process of high tech systems implementation as a process of mutual adaptation, of gradual convergence of systems functionality and performance over time.
Figure: Implementation Strategies (Eason, 1988)
Two product delivery paradigms dominate high tech development projects: single shot implementations on the one hand and continuous process systems on the other. The two can be likened to the difference in manufacturing between batch based and process centric production. A batch model constructs production as an assembly process; the finished product is built up over time by combining prescribed ingredients or materials in set amounts in sequence. The process model is also recipe driven; however a process based production exercise is continuous. The pharmaceutical industry employs the batch/lot style production model extensively. The food processing and drinks industry blends batch with process control, inputs and variables are controlled over time to produce a continuous stream of end product. In both manufacturing batch and process production the overall design vision is captured in the plan or recipe, a set of instructions to be followed to construct a well-specified finished product. Control and management is focused on reproducing the design to exacting precision at the lowest possible cost over and over again. Both manufacturing models attempt to ensure the production of the product conforms with the known design efficiently, accurately, and cheaply. However neither the batch nor the process models encapsulate learning effects. They are both static production models, mechanistic rather than evolving and highly appropriate in settings where producing the same goods in volume to high quality standards (reproducing the original).
We can see however the influence of these models on classical interpretations of the systems development life cycle. Delivery occurs after an exhaustive up-front design process that concludes with the production of the first copy/version of the system being delivered in the first user installation. The technical design process dominates the early stages of development after which the delivered system imposes learning demands on organizations and users if they are to reap the benefits of the new system. The practical reality is however somewhat different.
We already know however that implementation of high tech systems does not usually coincide with the final delivery of a system. Delivery is in fact one of the most contentious periods of a project’s life. Delivery crystallizes all the anticipated promises of a new system into a single ‘moment of truth.’ The moment of truth is multiple and inconclusive, involving each user and use moment, user interaction and system interaction. Use crystallizes the user’s transition from one system to the next. The transition may be from an existing system to an upgraded system, entailing minor changes in use, appearance and performance. Transition may be more radical, from an existing systems context to a markedly different one that demands difficult and radical changes by users as they attempt to adapt the new tool to use. Radical adaptation may involve new user behavior, knowledge, tasks, and skills, it may also negate existing behavior, knowledge, tasks, and skills. Delivery may also be into a new market, it may displace existing systems, it may even co-exist with existing and competitor systems, perhaps interoperate with them at some level.
MUTUAL ADAPTATION AS A METAPHOR FOR DEVELOPMENT/MAINTENANCE
While new product development projects are the hallmark of the knowledge economy, it is a commonplace acknowledged in the industry that innovations are never fully designed top-down nor introduced in one shot. High tech systems are often developed by being ‘tried out’ through prototyping and tinkering. Eric Von Hippel (2005) traced the history of selected technology innovations and arrived at a pragmatic realization that products continue to be developed even when they leave the confines of a laboratory or engineering shop. He develops the concepts of ‘lead user’ and ‘innovation communities’ and concludes that innovation is a process of co-production shared between the producer and the consumer of a new product. Innovation might therefore be thought of as maintenance; a collective and intrinsically social phenomenon resulting from the fluidity of systems undergoing cycles of design, delivery, learning through use that feeds back into further design, delivery and learning.
Proactive support in the form of ‘digital assistance’ has been built into high-tech systems through help menus, user guides, and tutorials. Automated issue reporting is also used to send reports and diagnostic traces (e.g. state blogs, configuration settings, memory dumps) directly to the producer when failures occur. Automated online updating and service pack distribution is also employed as a means of keeping customers installations up-to-date. Diagnostic and investigated analysis of user-click-streams may also be available for the producer to analyse and respond to actual user/customer behaviour. At the most fundamental level however, support activities must first link customer details with a description of the problem.
User issues fall into three main categories: corrective, perfective, and adaptive (Swanson, 1976). Corrective issues are the classic ‘bugs,’ performance and operational failures. Perfective issues address incremental improvements and performance enhancements. Adaptive issues are concerned with responding to changes in the operating environment thereby introducing new or altered functionality. Only one of these categories can really be considered to address failure. The other two, perfective and adaptive, imply that software maintenance is necessarily a design activity. The problem with software is the complex interdependencies within itself, its surrounding technologies and tools, and the environment it operates within. Therefore, changing software usually generates unexpected side effects.
Over time modern issue tracking systems have themselves evolved into general-purpose incident tracking and reporting environments. These development system applications (e.g. JIRA, MANTIS) are often used therefore as both incident repositories and as planning tools. In this way the maintenance process itself has, over time, evolved from being an end-of-life risk management and repair tracking process into a direct link between the user/customer and the development organization. Maintenance has therefore become a crucial source of feedback and a key driver for new product requirements. Issue tracking systems expanded to include the database of features under development and the workflows surrounding issues have been adapted to manage development itself.
We can conclude that software maintenance and new product innovation projects are more closely related than is commonly accepted. The activities of maintenance and support are important sites for the innovation of technologies in development, at least as important as the work of new product development.
