Establishing an infrastructure for productive development

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.

“Current software projects spend about 40% to 50% of their effort on avoidable rework”
-Barry Boehm, USC and Victor Basili, U. of Maryland

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 coexist 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.

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.

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. 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.

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.

2. Consistent Coding - Personal and Team Practices
Following established coding practices, which may vary from person to person and team to team, significantly improves productivity. These best practices include:

• Coding policies and standards: These are commonly based on collective team experience, single-handedly imposed by an expert architect, or derived from contract conventions. These policies don't need to be elaborate, but simply cover the most essential coding aspects and, of course, be applied consistently.
• Best practices against silly mistakes: Only the cream-of-the-crop of software developers can be reasonably certain that they don't make silly mistakes. Often, such mistakes happen not because of lack of knowledge, experience, or training, but just because of Murphy's Law, tiredness, distraction, and other human factors. It's best to have these checks implemented with automatic code analysis tools so that code can be checked quickly and thoroughly.
• Custom checks against defects already found: One of the best practices overall is never to make the same mistake twice. Many mistakes and errors, although personally specific, can be generalized and then automatically detected by custom guidelines or custom checkers.
• Checks for data- and flow-dependent errors: The trickiest errors often happen in specific corner cases, which may be dependent on program input data and the execution state, and typically aren't identified through manual testing. The new generation of static analysis tools can perform a very extensive search for errors (such as potential resource leaks, NullPointerExceptions, SQL injections, and other security vulnerabilities) without executing the source code they're analyzing.

Explicit published guidelines are critical to effective policy enforcement. The most effective way to enforce such guidelines is to check compliance automatically using code analysis tools. Automatic code analysis saves time, reduces the chances of issues being overlooked, and provides a reliable source of data for process monitoring.

3. Consistent Peer Code Reviews
Code review is one of the most powerful techniques to find defects and prevent sub-optimal software. Code reviews engage the human brain, which is a very powerful analysis instrument. Studies show that up to 90% of software defects can be eliminated by human inspections, with the average being around 60%. As a rule, code review needs to be done on any new code or critical legacy code to ensure that issues don't slip through. Historically, in many organizations, code review implementation is impacted by issues such as:

•  Lack of consistent coding policies and explicit guidelines
•  Review time is spent mostly on validating conformance with coding policy, not algorithm/architecture/reuse
•  Issues are not recorded
•  Resolution of code review issues aren't tracked
•  Scheduling/meeting logistics (especially for distributed teams)
•  High cost and induced boredom of participants

Some solutions address these inefficiencies better than others. Focused code reviews are known to work better on average, so a code review checklist (beyond a coding policy) should improve ROI and help address architectural considerations, code reuse, and proper use of components. Taking this one step further, automated code analysis relieves reviewers of the burden of checking compliance with coding policies. Additionally, to ensure that new code always gets reviewed; automating preparation, notification of code reviews, and tracking of issue status further improves the results.

4. Early Testing
On average, fewer than 50% of software defects are structural, and the rest result from missing or incorrectly implemented requirements. Finding such functional defects requires testing: exercising some portion of the software according to how it's expected (and not expected) to work.

"Early testing" is typically done at the unit and component level before the application is fully assembled. The two main goals of such testing are, generally, performing functional validation of implemented code and securing handling of corner cases. Good testing tools facilitate testing of incomplete systems by using automated stubbing at various levels, which is vital for test efficiency at that stage. Consequently, dealing with missing or incomplete dependent components becomes much easier than if you were trying to do it by hand. Again, automation helps productivity.

5. Automated Regression Testing
When many people hear the term "regression testing," they think of activities done by QA or test groups before a software release. This approach is more wasteful and less effective than the continuous testing approach.

With continuous regression testing, the software behavior previously captured by automatically generated and/or user-defined tests is verified by re-running the tests on a regular basis (preferably daily) and comparing the current results with those from the originally captured "golden set." This provides developers with a safety net when they're modifying code: they can rest assured that if they accidentally break existing functionality, they will be notified immediately.

The high value-add of this regression approach is that it's automated. It's impractical to have test groups retest the same thing over and over again every day or every week - they would all quit in a month. Moreover, tests need to be run frequently so that if problems occur, they are detected and repaired without delay. To run frequently, these tests must be automated.

Report and Track Results
The famous saying states that you can't correct what you can't measure. Hence, it's important to assess the impact of any new techniques added to the software development process. A reporting system is a vital component: it can be used both to check the pulse of development and to analyze any changes that result from improvement initiatives.

Any practical system should automatically collect relevant data from the software development process, analyze the data, and make it available to all team members and management in a convenient form - typically via Web access and role-based dashboards with drill-down capability.

Summary
Implementing an Automated Defect Prevention system benefits everyone involved, from the developers right through to the customer. This is not a silver bullet, but through dedication, strong leadership and clear goals to improve quality and productivity Automated Defect Prevention will immeasurably improve the company’s bottom line. The book on Automated Defect Prevention can be found on Amazon!