Static Analysis

Subscribe to Static Analysis: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Static Analysis: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Static Analysis Authors: AppDynamics Blog, Jason Bloomberg, RealWire News Distribution, Skytap Blog, Jayaram Krishnaswamy

Related Topics: Static Analysis

Static Analysis: Article

Establishing an Infrastructure for Productive Development

Countermeasures to development waste

Software development is an inherently creative process. Many developers compare it to art, and - like artists - take great pride in their work. However, creative processes are typically not efficient. The software development process is no exception, as the quote below clearly indicates.

Given that software development is a business, many software development managers and team leads want to make it more productive and predictable. Yet, they worry that such efforts will frustrate developers and impact the creativity that is vital for successful software projects.

Fortunately, efficiency and creativity can peacefully co-exist in the software development process. When the more mundane aspects of development are automated, developers can focus on the creative tasks they enjoy most…and still deliver better software in less time. This article explains how five industry-standard practices reduce the amount of avoidable waste in the software development process, enabling developers to satisfy business goals without compromising their craft.

Fewer Bugs or Shorter Schedules?
Surprisingly, the fastest schedule is actually one with a very high defect removal rate. Consider Figure 1, which is taken from Capers Jones' Applied Software Measurement: Assuring Productivity and Quality, 2nd edition (McGraw-Hill, 1996).

This graph, which is based on industry statistics, shows the relationship between total development time and the percentage of defects removed before a software release. As you can see, the development time steadily declines until the 95% defect removal rate is reached then it spikes as the percentage of defects removed approaches 100%.

These findings show that - contrary to popular belief - delivering better-quality software doesn't necessarily take more time than lower-quality software (i.e., software with more defects). Rather, the optimum schedule is attained with a pre-release defect removal rate of 95%, which is quite high in terms of software quality. This development point results in both the shortest schedule and a very low percentage of defects. Removing more defects will likely improve perceived quality, but dramatically increase development time.

Two key points to take away from these findings are:

  • Defect removal doesn't occur "naturally." It requires the engineering team to proactively adopt appropriate practices and tools.
  • Most organizations are admittedly in the sub-optimal area of this graph. This means they can not only im-prove the quality of delivered code, but also produce the code at a lower cost.

Examples of Waste
The first step in moving towards this optimal development zone is identifying the kind of waste that can and should be avoided. Granted, there's some unavoidable waste inherent in the software development process. For instance, examples of such waste include basic R&D that doesn't get productized, prototyping, and so forth.

The scope of avoidable waste, however, is quite substantial. It can include:

  • A day spent fixing a build break that occurred because someone checked in code without locally compiling it. This happens more often than most managers think.
  • Two weeks spent debugging a missing curly brace. This seems incredible, but can actually occur when the team is looking at functional manifestations of this error and trying to debug the error from that end.
  • Figuring out what the heck this variable g stands for. This is a result of poor naming conventions.
  • Nominal case design and development. This is typically a result of ignoring corner case conditions.

Notice the common thread here: a lot of waste stems from late detection of defects that could have been found much earlier or prevented altogether. This applies to all types of defects - including missing requirements, lack of error checking for unexpected user actions, or structural code problems.

Motivators for Waste Reduction
One benefit of reducing waste is that it allows your team to reach a development point that results in reduced development time and a very low percentage of remaining defects. Thinking back to the "development time versus percentage of defects removed" graph in the earlier section, the organizations that are in the optimal area of their development cycles are those that dramatically reduce their waste by targeting defect removal earlier in the process. Thus, they achieve both higher quality software and lower development costs.

The other tangible benefit of reducing waste is that it improves the professional life of developers. Their job satisfaction typically goes up when they're relieved from having to spend excessive time fixing bugs (unproductive work), and can instead focus on the creative tasks they enjoy the most.

Five Countermeasures to Development Waste
Five cornerstones that have been proven to reduce development waste are:

  • Robust development infrastructure
  • Consistent coding - personal and team practices
  • Consistent peer code review
  • Early testing
  • Automated regression testing

Finally - and most important - reducing waste in a systematic manner also requires a reporting system that enables teams to track qualitative progress towards their goals for all five of the above countermeasures.

The strategies above are explained in the following sections.

1. Robust Development Infrastructure
A robust infrastructure automates repetitive tasks, organizes project activities, tracks project status, and seamlessly collects project data to provide measures necessary for decision making. Most of all, this infrastructure sustains and facilitates the improvement of human-defined processes. 

Figure 2 illustrates the foundation of a robust development infrastructure.

This foundation comprises the following components:

  • Source control system: The source control system provides a central place where the team members can store and access the entire source code base. It gives each developer the freedom and safety to write, modify, and re-factor code on his or her workstation. Having a source code repository is also a prerequisite for regularly scheduled automated builds. All of the files needed for the build should be in the source control system, including build files, scripts, etc. not just the source that is being built.
  • Nightly build system: The automated build system builds an application on a regular basis by automatically executing the required build steps at the scheduled time without any human intervention. Without an automated nightly build, development quickly gets out of control and waste increases. Ideally, builds run nightly. This way, any problems are detected the next day (as opposed to a week or more later). However, the key is running them on any type of regular and frequent basis that suits your needs. Unless regular builds are run in an automated fashion, the probability of producing working software on time drops dramatically.
  • Requirements management system (and/or bug tracking system): This is a repository for storing and tracking defects and issues, as well as the developers' ideas for improving the application. Defects are stored so they can be tracked, analyzed, and ultimately prevented from recurring. The system can also be used for storing feature requests and tracking feature and requirement changes. The end result is a central repository of information related to your software.
  • Regression testing system: A regression system is any tool or combination of tools that can automatically run the core of the existing tests on the entire code base on a regular basis. For example, the regression system may be a script that runs one or more testing or defect prevention technologies in batch mode. Its purpose is to identify when code modifications cause unexpected faults, especially those faults that occur because a developer didn't fully understand the internal code dependencies when modifying or extending code that previously functioned correctly.
  • Other tools: This can include tools for static analysis, code review automation, performance profilers, memory analyzers, coverage analyzers, etc. - whatever automation the team finds reasonable (or can afford) to leverage for productivity.
  • Reporting system: This system should be able to gather data from all these components (source control, nightly build, tests, etc.) and present them in a visual way to enable status and trend analysis.

More Stories By Sergei Sokolov

Sergei Sokolov is a senior member of the Professional Services team at Parasoft, a provider of software development tools that help control and optimize the software development process.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.