Instead, you can manage the culture and then let the culture manage the group by means of self-regulation, cooperation, peer pressure and other means. Starting in this column and concluding in next month's, I will discuss ways to establish and foster a self-regulating group culture in software development teams.
Code ownership
The most important element of developing group culture is code ownership. Code is the group's greatest asset because it is the main thing that it has to show for all of its work. It also serves as means of communication: Just as mathematicians communicate their ideas most precisely with equations, developers communicate their ideas most precisely with code. By protecting the quality of their code, developers can preserve their best ideas in the clearest, most concise way possible, as well as ensure that their communications are as effective as possible.
Because code is such 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 toward the code reflects the code's importance.
It's fundamental that everyone feels that they have a stake in maintaining high-quality code. This prevents group members from doing anything that harms code quality -- if they care about the code, they won't hack at it, shortchange it, wire it, etc.; they will always try to ensure that it is solid and working. This, in turn, fosters the growth of other fundamental elements of a self-regulating group (such as self-discipline and cooperation).
Moreover, it also helps filter "bad apples" out of your development team. In an environment where group members feel a strong investment in code quality, any developer who does not care about the code will alienate himself from the group. Most group developers will soon become frustrated with someone who constantly introduces problems into the code and will try to help this developer improve. If he does improve, the group is stronger; if he does not, group conflict will generally lead him to leave.
Code ownership should be balanced by what is called "egoless programming." The point of egoless programming is that the group owns the code; each developer takes responsibility for the code, but each developer should not take criticism of the code he wrote as a personal attack. If a developer is overly sensitive to constructive criticism, he probably won't grow as much or as rapidly as developers who can handle it. If you find that you have a developer who takes this type of criticism personally, you should sit down with him and explain that you are trying to help him improve his abilities and the quality of the code.
Code reviews
The best way to ensure that each group member understands the importance of preserving code integrity is to implement practices that help ensure and maintain quality.
One of the most important practices is properly implementing code reviews. The purpose of code reviews is to exchange ideas about how the code is written and to establish a standard group interpretation of the code. The most effective code reviews focus on tasks that can't be automated.
Developers should be given the opportunity to explain their code to one another. Often, simply explaining the code exposes problems that could later lead to errors. When the group members discuss the code, their discussion needs to focus on important issues such as algorithms, object-oriented programming and class design.
However, many code reviews do not do this; most are dry, boring and mechanical, which is why many developers hate them. For code reviews to be effective, they need to be fun and create ideas. Very often, they deteriorate to focusing on enforcing coding standards. When this occurs, groups usually decide that code reviews are not valuable, drop them from their development process and lose the potential benefits that can stem from a correctly implemented review.
If you want a code review to be successful, you should ensure that it does not involve routine coding standards checking. Coding standards enforcement is a valuable way to prevent errors that affect application reliability, security and performance, and to improve code maintainability and reusability. However, coding standards can be enforced more quickly, accurately and objectively when automated tools are used to check compliance as the code is being developed. Code review time may be needed to discuss suppressions of reported rule violations in exceptional contexts, and/or to recommend coding-standard modifications and tool configuration changes.
Nightly builds
Another fundamental element in establishing code ownership is a process that I call nightly builds. A nightly build is a completely automated process that rebuilds the application overnight, every night, without any human intervention. At the same time each night, the build should check code out from the code repository, rebuild the application and run test suites. When the developers come in every morning, they should see a report that contains any failed test cases and be able to immediately assess project progress and quality. This enforces the self-regulating mechanism, because it helps the group benchmark itself and assess the quality of the code. It also helps expose problematic developers and encourage them to improve their skills.
For example, if a developer checks in code that does not compile, the nightly builds (as well as frustrated group members) will constantly remind him of this problem; generally, that developer will then either decide to use the available resources to improve his coding habits or leave the group. Nightly builds also help enforce common working hours (which, as I will discuss next month, help hold group culture together): Because nightly builds need to begin at a certain predetermined time, all developers who want their code incorporated into the build need to check in their code before that time and generally go home before the build begins.
-- Adam Kolawa is co-founder and CEO of Parasoft, a vendor of automated error-prevention software and services based in California. Co-author of Bulletproofing Web Applications (Hungry Minds, 2001), Kolawa has contributed to and written more than 200 commentary pieces and technical articles for numerous publications. He holds a Ph.D. in theoretical physics from the California Institute of Technology.