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?

  • 1
    Your "cult of quality" will only be as effective insofar time allows. When the boss says 'It has to be done by Friday', then you are forced to drop quality for speed. Obviously this is not what coders prefer. Ideally we prefer time to ensure quality!
    – invert
    Commented Feb 4, 2011 at 13:16
  • 1
    @WesleyWerner : Good point. But I think that a 'cult of quality' should also embrace taking care of technical debt, which will (eventually) solve the boss problem you mention.
    – talonx
    Commented May 9, 2012 at 5:04
  • @invert: I typically reply in such cases, that we have a situation analoguous to the CAP theorem here. We have quality, speed and manpower, and he may choose two.
    – JensG
    Commented Jan 17, 2014 at 19:37

4 Answers 4


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.


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

  • 4
    A dangerous advice. What if the OP belongs with the 2nd/3rd group? ;)
    – user8685
    Commented Feb 3, 2011 at 23:14
  • 1
    great answer, I'd never thought about it like this, but it makes so much sense.
    – Alb
    Commented Feb 3, 2011 at 23:15
  • 9
    @Developer if they were, they wouldn't be reading DeMarco and Lister or asking the question here.
    – Alb
    Commented Feb 3, 2011 at 23:16
  • I thought the question was more directed from a team-member point of view. If management really wants quality, they will listen their top/core developers. What I, as a team-member, not a manager, can do to improve my team's code quality ?
    – Machado
    Commented Feb 4, 2011 at 0:04
  • 1
    @Thorbjørn, excellent question! I admit I have been missing this in most of my workplaces so far. Hoping not to sound too self-aggrandizing, I have always been looking for teammates to look up to and to learn from, but I rarely found them. So I turned to books and the internet. As much as it is possible, I found role models in Martin Fowler, Uncle Bob Martin et al. And lately in the SO community! It is a terrific place to learn. Also a potent "reality check provider". The humbling experiences revealing limits of and gaps in one's knowledge can be hard to take, but are very healthy for me. Commented Feb 4, 2011 at 9:38

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.

  • +1 Good points about motivation. I was apparently misunderstandable regarding the majority; I updated my answer to clarify. Commented Feb 4, 2011 at 9:22

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.

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.