In-Depth
A Three-Step Program for Improving Software Quality
Reliable, high-quality software can be yours if you incorporate these three principles into your development
Have you long been searching for the end-all be-all solution for producing reliable, high-quality software? As you've seen in the automobile, electronics, and consumer goods industries, there is no “silver bullet” for producing quality products. These industries have proven that quality is an expensive process that must be built slowly over time.
The software industry—and the development efforts within your IT department—should be no different. Your organization must approach quality in the same manner. Unfortunately, quality is often the last thing on the minds of developers. To reap the many rewards from producing quality products, developers’ approach to creating software must change and quality initiatives must be put in place.
How can developers change their way of thinking? What does it mean to write quality software? More importantly, what are some of the practical steps for achieving quality? These are complex questions, and depending on whom you ask, you are likely to receive diverse answers.
When introducing quality initiatives to your software development team, you must consider customer requirements, tools, planning, management infrastructures, and much more. Perhaps the most important requirements for software development quality are creating group culture, and properly utilizing source control systems and automatic builds. I will discuss how you can establish these initiatives within your development process. Follow these basic and practical steps and you'll establish a fundamental base from which to improve the quality of your software.
Step #1: Create a Group Culture
Group culture is a development team's way of working together, including their shared habits, traditions, and beliefs. A positive group culture should promote code ownership, group cooperation, peer learning, common working hours, and mutual respect. When managers and leaders focus on developing and supporting a positive group culture, the team is typically more self-regulating, creative, effective, and satisfied.
Because most companies employ separate divisions for code development and quality assurance (QA), group culture is often lacking. The separation of development and QA leads to many software problems and inefficiencies -- developers will write code assuming that someone in the QA department will inject quality into the software. When problems occur, the code just bounces back and forth between departments without anyone taking responsibility.
To remedy this problem, establish a positive group culture within your organization. Merge two groups under the same management, or try eliminating the QA department altogether, forcing developers to take ownership of their code. It is crucial that developers buy into the quality of the code they create. This parallels the teachings of W. Edwards Deming, a businessman who revolutionized the manufacturing industry in the 1930’s. Deming found that you cannot separate the responsibility of production from the responsibility of verification—these responsibilities go hand in hand. If you separate these responsibilities, you can never achieve quality.
Code is an important expression and product of the group; caring about the quality and success of this code is fundamental to group culture. It is the glue that holds a group together. You want to build a culture where the developers’ attitude towards the code reflects the code’s importance. Developers should show that they care about the code because caring about the code is synonymous with caring about the group. If a developer cares about the code, he will care about the group, and if he cares about the group, he will care about the code. It’s fundamental for all staff members to recognize their stake in maintaining high-quality code.
Step #2: Properly Utilize a Source Control System
A source control system is a database where source code is stored. Its purpose is to provide a central place where the team members can store and access the entire source base. Most organizations do not understand how to effectively use their source control system. Many simply underuse their source control system, don’t require its use, or improperly configure it for the group environment. To put your source control system to proper use, it is important that you understand and establish guidelines for your developers. Source control systems are so important that without a properly configured system, quality software cannot be made.
Developers should not have any code on their machine that is not already in the source control system. Source control should allow developers to shadow (i.e., copy) code that is already available in the repository, modify code that is already available in the repository, and add new or revised code to the repository. Developers should never check in code that has not been compiled. The moment code is written, developers should resolve all compilation errors and compile-level warnings.
These principles may sound obvious, or even naïve, but many software organizations lack a clear policy regarding what code can be checked in and out of their source control systems.
Tips for Using Your Configuration Management System
When you use a source code repository, you can track the history of the code and improve efficiency by ensuring that revisions are not carelessly overwritten. The ability to revert back to archived versions also enables you to take risks with your revisions and to start over when so many bugs have been introduced that recoding is easier than debugging. There are many proprietary solutions for managing version control, known as configuration management systems.
Configuration management tools have many features that are meant to aid the developer. Although you can use a tool as is, I recommend you customize it to your team's specific needs. Many of these features are counter-productive and error-prone.
One such problem is the parallel development feature that allows two developers to work on the same file simultaneously. After the developers make their modifications to a file, they check it back in, and the system is supposed to merge the modifications. This is a completely and utterly useless feature of version control systems. In fact, parallel development merges two very different pieces of code that were modified without regard for each other, and introducing bugs as a result. Block this feature from your configuration management tool and establish guidelines that allow code to be modified by only one developer at a time.
Another counter-productive feature is versioning. Many developers are under the impression that they can work with and modify different versions of code. What they don’t realize is that errors may occur because modifications are sometimes made without paying any attention to which version they are trying to fix. A developer may fix a problem in one version while creating numerous errors in another version. Instead of depending of the versioning feature of their configuration management tool, developers should version their code by hand and keep an independent copy of the software in an independent source control system for each supported version. When a version is no longer supported, the entire source control system for that version should be archived and stored.
Using a Sand Box
A sand box is used by developers to store copies of all files that are part of the software project. For each project, keep one sand box (called the "Build" sand box) that is cleanly shadowed from the source control system and deleted on a daily basis.
In addition, each developer should have an individual "Developer" sand box; it should be cleanly shadowed from the source control system according to the individual developer’s needs. None of the files in the Developer sand box should be checked out for extended periods.
Once a developer is finished coding a feature, he should delete all files from his Developer sand box and then shadow a new copy. This way, the sand box stays in sync with the source of the application.
Step #3: Properly Use an Automatic Build Process
A well-planned build process should:
- provide early detection of incompatible changes in the application components
- ensure that the application continues to run as expected
- detect any errors introduced by newly integrated code
However, as with source control systems, software companies have automatic build systems in place but misunderstand the scope of automatic builds and thus do not use them properly.
An automated nightly build is the process of building an application every night through an automated build system that will automatically execute the required steps at the scheduled time without human intervention. For greatest effectiveness, automated nightly builds should start with a clean slate by pulling all necessary code from the source code repository into an empty Build sand box, then compiling the necessary components and building the application. Next, the application should be delivered to a staging area for further testing.
A staging area is a private version of a complete Web application. The staging area can be as complicated as an N-tier system, or it can be a very simple system. A staging area provides a safe zone where application modifications can be tested before they are made live. This way, errors can be found and fixed before they reach the public. Some files (such as images and static pages) can be thoroughly tested without a staging area, but dynamic functionality (such as programs, database connections, and the like) cannot.
Upon success, the automatic build process should also run all available test cases and report any failures. This way you can verify that no code has slipped through the tests that developers should perform before adding their code to the source code repository.
Conclusion
In order to develop software quality, you must begin with the basic principles of creating group culture, and effectively using your source control system and automatic build process. By adopting these basic principles, you will be able to prevent errors and improve the quality, functionality, and performance of your software.