How to create a "cult of quality"

Question

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?

Answer 1

My experience is that development teams (but in general, any team) consist of 3 types of people:

• those with a built-in drive for quality,
• those who are only in it for the money (beer / girls / whatever) and couldn't care less however you try to motivate them,
• the "mediocre" ones (for lack of a better word).

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.

Update

@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:

• Keep learning and spread the knowledge around to anyone who listens. Learn and use the best practices within your areas of expertise.
• Take pride in your work.
• These two will almost naturally let you become a positive role model for others - especially newcomers and juniors -; be conscious about this, and leverage your role for the benefit of the whole team. The best way to influence others is by positive example.
• Look not only at the code, but at the whole process of developing software; keep asking questions and providing feedback to optimize the development process.

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.

Answer 2

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.

More specifically:

• Remove any trace of the thinking 'We will clean it up later'. Instead put in the effort at the beginning to get it done the correct way.
• Require that changes get reviewed and worked through some sort of QA process involving someone other than the developer.
• Force thoughts about quality in early phases of projects. Keep things like "how easy with this be for others to maintain" in focus during development.
• Track and report on bugs that occur. If there are trends look at ways to combat the root cause of the bugs.
• Introduce the thought of software as a craft that can be improved upon and something the creators can be proud of.

Answer 3

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.

Answer 4

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.

• Provide a solid community for belonging.
• Give an environment where the employee feels free to make mistakes so that they can build up esteem when they make accomplishments.
• Hand your developers the reins so that they can make the important decisions for 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