DeMarco and Lister (Peopleware) suggest you create a "cult of quality" within your programming team. Frustratingly, they don't suggest how you go about doing that!
Anyone got any thoughts on how to accomplish this?
My experience is that development teams (but in general, any team) consist of 3 types of people:
The last group is the largest, and they tend to follow the ruling party. If there are enough quality people in the team, they can pull the majority with themselves, creating a strong upward spiral in team spirit and motivation. However, if there are too many slackers, they can easily create the opposite effect, a spiral of death.
So the foremost task for the manager is to choose and keep the right people and get rid of the bad ones asap. Not the "mediocre" ones though - they may be influenced to start improving, to lend support for others' good ideas, and some of them eventually might even become positive trend setters on their own right.
[Update2] reflecting on Alb's answer: IMO there's no need for the quality developers to be in clear majority within the team (although it doesn't hurt :-). There is a "trend setting threshold", above which the views and behaviour of a subgroup can quickly become the "mainstream" within a community, so other people take notice and start to follow. You can see this in work in the larger society all the time (e.g. (non)smoking habits, health & diets, pop fads, organic food). My very rough estimation is that it can be somewhere around 25-30%, but it depends on a lot of factors. This is where the bad people can hurt a lot. Even a couple of bad people within your team can raise that threshold significantly.[/Update2]
Of course it is not always possible to hire enough of the top guys. So when the first faction is not strong enough to drive things on their own, management needs to help them. A couple of thoughts on this:
I think that Scrum has a good idea for this with product demos. Demonstrating the feature you implemented in front of an audience consisting not only of your teammates but possibly developers from other teams, management, even users of the app can be a huge source of pride and also a strong factor to help the team jell.
Another thing is for management to listen in earnest to the dev team regarding quality. DeMarco and Lister even mention that there are companies/departments where dev teams have a veto over what can go to production. If they feel the app is not yet ready for prime time, they can postpone the release regardless of what management would like. Now that is tough for management, but I can imagine that it builds team spirit and strongly communicates the message that quality is really important here, not just on the level of words.
This leads to the next point: to create a "cult of quality", management must thoroughly understand what most experienced developers already know: that quality is not an afterthought - it has to be built into the product from the start. So people should be encouraged to (and rewarded for!) thinking about long term maintainability, striving for the good solutions, instead of the quick ones.
@Machado in his comment gave a new twist to the question (to me at least):
What I, as a team-member, not a manager, can do to improve my team's code quality ?
A few thoughts:
And last but not least: find a place where you can be a "top guy". If you are in the "mediocre" group right now, strive to develop yourself - hopefully the above ideas help in that. But if you happen to be in the "lower strata" in your current team, I recommend you to analyse the reasons. What is it that demotivates you? Bad working conditions? Teammates? Management? Type of work? And what is it that excites and interests you? You may need to talk to your coworkers and/or boss about it. Or you may need to look for a better job - or even a new profession - where you can start shining. It is really not worth spending a significant part of one's life with unsatisfying or depressing activity.
It may also be that you are forced to continue your current, suboptimal job due to external factors (lack of better job opportunities, need to pay the bills etc.) - it happens every now and then. Even in this case, try to make the best out of it. Producing quality work (as much as circumstances allow it) is a reward in itself, which helps keep your self esteem up, and keep yourself sane and open in the long run. Thus when an opportunity for something better appears, you are better prepared to take it.
Great answer by Péter Török to highlight that you'll only manage this with a majority of good people. Once you have good people you need to aim more for the carrot approach rather than the stick. Empower the developers, let them take ownership of projects/tasks and encourage competition in terms of quality, maybe have people give short presentations on how they improved qaulity in projects. Good developers will be motivated to impress their peers.
In addition to Peter's comments (which are really the core issue), you need to make sure quality is not a feature that is added later.
I would say that the best way is to encourage quality over output. This is one of the premises of the Lean Software movement (based on Lean Manufacturing). I've written a long blog post discussing what Lean is all about. I tell you how to create a cult of quality. Invest in your employees and let them invest in your company (not monetary investment, but rather a personal investment).
Dan Pink gave a great talk at TED about what motivates us. While he doesn't reference it specifically. Maslow's Hierarchy of Needs explains the observed phenomenon perfectly. As long as the employer addresses the first two needs (i.e pay enough money so that money is not a problem) all that's left is Belonging, Esteem, and Self-Actualization.
Quality is not something that can be dictated...rather it is enabled. Trust your employees to do what's best and get out the way. Eventually, you'll have to tell them they need to leave. Rather than asking them to put in more hours