As I mentioned in my last column, establishing an effective, self-regulating group culture offers a tremendous benefit to managers: It allows you to effectively guide the group by managing the culture rather than micromanaging the team members.

Previously, I discussed how managers could use code ownership, code reviews and automated builds to promote a self-regulating group culture. This month, I'll discuss how bug-tracking systems, developer self-discipline, cooperation, peer learning, common working hours and respect can be used to foster an effective group culture.

Bug-Tracking Systems

Bug-tracking systems can play a significant role in building group culture. Very few people think about these systems in this way because they are primarily used to keep track of developers' mistakes. But developers will access and love a bug-tracking system if you ensure that it provides valuable information about their products.

One potential use for a bug-tracking system is as a repository of developers' ideas for current or future releases. This shows developers that they are the driving force behind future projects and releases and increases their investment in their success.

When you are deciding which ideas to include and which to leave out, keep this in mind: You should never discount developers' suggestions; it discourages them from creating and sharing new ideas, and this restriction can choke a group's success.

While not every idea might be good, every idea should be accepted. As time passes, people will think about and discuss the ideas that were recorded; flawed ideas will be exposed as such and either be replaced with better ideas or just die away.

Developer Self-discipline

After you've established this infrastructure that encourages code ownership, you will begin seeing benefits. From a management standpoint, the most valuable benefit is self-discipline. The more you stress the importance of code quality and the more strictly you implement an infrastructure that maintains code quality, the more self-disciplined the developers will become.

The best groups are managed by their group culture, not their managers. Managers should make sure that the group members have the necessary help and resources that they need to perform procedures correctly, but they should not have to ensure that they perform the procedures.

When developers understand the importance of code quality and its effect on the group, they strive to write solid, reusable code, and independently apply processes known to check and improve the quality of their code. If you want to promote this self-testing, you should provide them with processes and technologies that allow them to perform this testing in the most efficient manner possible.

Cooperation

Increased group cooperation is another result of constantly stressing code quality. If one group member has a problem and the others are serious about quality, they will help him solve the problem. If the problem is the developer's fault (e.g., if he was wasting time), the entire group (not just the manager) should help him but make him aware that the problem was his responsibility and shouldn't happen again. In this way, interest in maintaining code quality creates the peer pressure needed to drive a group to regulate itself.

Peer Learning

When developers work on code together, they naturally learn from one another because each group member is an expert in a certain topic or technique and shares this expertise with the others. But because constant learning is so critical to developers' success, you should not leave learning to chance: To guarantee that developers are learning from one another, you should establish the regular code reviews discussed in my last column.

Common Working Hours

There is one common thread running through all of these elements that affects group culture: Developers must share their thoughts as they are creating code and solving problems. The more they work together as a team, the better they will communicate, the more efficiently they will work, and the more they will be driven to do whatever it takes to ensure the success of the group's projects. In order to do this, the developers need to be working approximately the same hours. If you have developers setting their own hours, these elements will not be established because there will not be enough common working hours to foster their growth.

This brings us to look at optimal working hours. The precise hours that you establish are not important. But if your team is geographically distributed, it is especially critical that you establish and maintain common working hours for both local and remote developers. If you don't, you'll have a tough time keeping the group culture together.

Respect

Above all else, if you want happy, productive developers, you need to treat them with respect. If the developers don't feel that their talents are appreciated, they are quite likely to go elsewhere.

If you invest resources in helping them grow, it's a win-win situation: The developer improves and sees a benefit in staying with your company, and you gain a happier, more valuable developer.

You need to assume many roles in order to achieve success. You must alternately assume the roles of coach, friend, boss and psychologist. You must also be technically savvy; if you can't look at developers' code and tell them what works, what doesn't and why, you will never gain their respect, and you will never be able to help them grow.

Adam Kolawa is co-founder and CEO of Parasoft, a vendor of automated error-prevention software and services in Monrovia, Calif. 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.