Prima Donna Syndrome

Jan Vermeir

Development teams or even development organizations, are not always the well balanced, smooth operations we'd like them to be. In our software quality audit practice we have had the privilege to investigate many different types of organizations and found many different ways quality and productivity can suffer from a problem known as the Prima Donna Syndrome: a single individual exercises a disproportionate influence on the team causing problems like stagnation and unnecessary complexity.

A Prima Donna is known outside of the software development world as the star of the opera, the one singer who can turn a nice evening out into an unforgettable experience. Sure, other vocalists and dancers are important, but their influence on the overall result is negligible. If the star of the show has an off-day, it doesn't matter how well the rest of the cast performs; if on the other hand the star of the show is at his or her best, the audience will reward the cast with a standing ovation. Of course, the Prima Donna starts using this status to make demands that may gradually become absurd.

A software development team can suffer from a similar affliction. If one of the developers on the team is much more experienced than his team mates, it is only natural that this person has control over most of the important decisions. He may feel he is the only person on the team capable of setting directions, choosing architecture, modularization, selecting libraries, tools and build infrastructure. Others follow or leave and gradually the imbalance in the team grows. Because the Prima Donna knows best, he will get an important vote in hiring new team members. To defend his position he will favor docile people who are more easily controlled, and the team suffers even more.
The effects on software architecture can be devastating. The Prima Donna doesn't need understandable code. On a small scale this isn't so much of a problem, but in a large software project you may end up with unmaintainable spaghetti. Other team members may be unwilling or incapable to make changes to code developed by someone else for fear of breaking something or just because they can't get their heads around it. Lack of shared ownership of a code base leads to duplication, dead code, more code and more duplication and so on. New developers face a steep learning curve, taking years to become productive.

So how do we get rid of this imbalance?

The first part of the solution is to spread responsibility among groups of team members by setting up feature teams. The main idea is to set up teams that will implement a small part of the system. Each team has representatives from all disciplines necessary to finish the job: designers, business logic experts, DBA's and service developers are all part of a small team that will implement a feature in all its aspects. Besides allowing you to deploy small features quickly, the consequences are that people are part of a small focused team that will learn to make its own decisions. The team will have more body and will be better equipped to work with the Prima Donna, who gets a new job: keep an eye on the overall consistency of the work done by the feature teams and make sure all features work together well, make sure the architecture remains sound.
A second job for the Prima Donna is trouble shooting: if there are hard to diagnose problems in production it takes in depth knowledge of the system and the platform to find a solution, often under time pressure. This kind of work is the sweet spot of a real Prima Donna's skills.

Comments (4)

  1. jp - Reply

    April 27, 2010 at 5:28 pm

    we avoid this problem by keeping high our own project-management-metric, the truck number*

    [* = the truck number metric signals the number of people that a truck has to run over in order to make the project a failure. The higher the number and the happier the boss are in strict correlation]

  2. Jan Vermeir - Reply

    April 28, 2010 at 9:24 am

    ooowwwkkaaaay.... I see. The truck number. The question now is:
    - how do I calculate the truck number without actually hurting people?
    and:
    - given the fact that the truck number is too low, what do I do about it?

    The correlation you noted with boss-happiness is interesting, but I guess it is only a secondary measurement that is influenced by many other factors (like programmer productivity, number of bugs, yesterdays alcohol abuse ...). So a happy boss may or may not indicate a healthy truck number.

    Just taking a shot at answering the truck number question, how about this:
    - Use your version control system to find out the LOCs changed by each developer
    - Sort the list in descending order by LOCs changed
    - Split the list in two at the 80% line (the developers above the line have made 80% of the changes)
    - Count developers above the 80% line gives us the truck number

    Anyway, thanks for your comment.

  3. jp - Reply

    April 28, 2010 at 3:40 pm

    well, I guess "truck number" stands for some type of metaphore, no actual need to take over people. Answering the question "How many people can be taken over by a truck, just before the project goes in trouble?" gives you a rough estimate.

    You can find more information on Ward's Cunningham wiki: http://c2.com/cgi/wiki?TruckNumber . How yo can increase this metric: pair programming, writing things down, having collective code ownership, all things noted in the post, etc.

  4. [...] This post was mentioned on Twitter by Gavin Harvett. Gavin Harvett said: What's your #Agile project's "Truck Number"? http://goo.gl/Gs5V - See blog Comments... [...]

Add a Comment