Monday, January 23, 2012

The Problem of Communication in Software Change Management

In our previous discussion of software change management, we focused on analysis and identification problems. This is only one of the problem areas in software change management that have been identified in studies in the field. Other problems that tend to recur related to software change management include communication issues, decision-making challenges, effectiveness roadblocks, traceability issues and problems with tools. As we examine each of these areas, we can see that a number of important issues frequently appear, especially when third-generation languages (3GL) such as Java, RPG, COBOL and various C-languages are involved (C, C#, C++).

In this post, we will review at a high-level how communication issues in software development and software change management can lead to problems. How can we overcome communication issues between developers, business analysts, stakeholders and users to ensure more effective and satisfying outcomes in application development?  Are there changes that can be made in the way we approach application development that will tend to reduce the impact and likelihood of errors?

Concurrent or parallel development can cause a need for greater and more frequent communication between developers, business analysts, stakeholders and users. This slows down progress overall and introduces the likelihood of communication errors and misunderstandings. This is especially true when communicating with non-developers. Developers figuratively “speak a different language” and this introduces a greater possibility of misunderstanding. Non-developers and developers can hear the same words and can take away different meanings. In addition, developers and non-developers will tend to attach different contexts, priorities and values to the meaning of communications. The need for greater communication caused by concurrent development, leads to a greater number of possible miscommunications leading to errors and unmet expectations.

Use of shared software components also exacerbates communication issues. Communication is required between more developers because of the shared nature of components. Developer A cannot simply change Component Y without considering the potential effects on development by Developers B, C, and D. This results in the need for distributed decision making on changes to components. Since computer languages are only readable by specialists, explaining the potential ripple effects of component changes can involve the need to communicate with multiple groups of business analysts, stakeholders and users.

A number of strategies can help to overcome these and other communication related issues in software development to help ensure more effective software change management. It is essential to have a communication plan, style and approach for development projects. The use of team development tools for source code control and other issues will tend to help avoid communication errors as well. Whenever it is possible to leverage more advanced development approaches to reduce the number of developers, this will have positive impacts on communications as well. More frequent development cycles by using agile or SCRUM development principles will likely improve communication as well. More frequent prototyping becomes very useful in reducing communication issues. Where human language fails to adequately portray software, prototypes can provide actual or simulated experiences that overcome communication and comprehension barriers. Leveraging repository-based development approaches provides a context for visualizing dependencies that is more effective than scanning a code base, for example. Making use of pre-compiled application platform capabilities will greatly reduce the development effort and minimize communication issues, especially thorny underlying issues in the environment that typically fail to capture the attention of business stakeholders but that can often lead to fundamental differences in judgment of software quality and completeness. If the platform selected allows for the leveraging of .NET based components in client-side development, there can be significantly fewer communication challenges as well.

More effective software change management hinges to a great degree on overcoming communication issues in software development. In our next entry, we will consider the question of effective decision-making or governance as a source of errors from a software change management perspective.

Wednesday, January 18, 2012

The Problem of Analysis and Identification in Software Change Management

Studies in the field of Software Change Management have helped IT managers to identify a number of problem areas in software development. Problems related to software change management tend to occur in five areas: analysis and identification related problems, communication issues, decision-making challenges, effectiveness roadblocks, traceability issues and problems with tools. If we examine each of these we can see a number of important issues that frequently crop-up, especially within third-generation languages (3GL).

Today, I’d like to focus on a high-level review of analysis and identification related problems in software change management. How can we identify and analyze problems in our software to best understand and realize where we have errors that require correction. More importantly, how can we change our approach to application development in a way that reduces the impact and likelihood of errors?

Analysis and identification problems can be seen in several areas. First of all, problems with analysis and identification are driven by concurrent and parallel development approaches. The problems occur because with concurrent efforts it becomes more difficult to determine root causes of program errors. This is exacerbated by the fact that standalone testing does not find the problems leading to the error conditions. Solutions can be found by reducing the number of developers, engaging in  more frequent cycles (such as with agile development or SCRUM), testing without compiling and ultimately by delegating more basic functions to an application platform in a post-3GL approach.

Another factor driving analysis and identification problems is code optimization. For one thing, optimized code, especially optimized C, C# and C++ code is very difficult to understand. In addition, with optimized code, object oriented development tends to create a ripple effect that is not apparent in typical source. Code optimization issues can be avoided by leveraging pre-optimized code, i.e., avoiding heavy 3GL development projects with more advanced development platforms.

A third factor leading to analysis and identification problems comes from the use of shared software components. Here we see impacts across the code base and ripple effects. These can be avoided through better pre-planning, wise use of inheritance principles and by leveraging a platform rather than resorting to line-by-line coding.

The need for high reliability makes the problem of analysis and identification of the impact of software changes particularly important. It is difficult to predict the impact of changes and at times corrective actions may seem difficult or impossible. Avoid this sense of being overwhelmed by engaging in iterative development and testing. Make use of an application platform to better overcome challenges in the analysis and identification of software change management problems.