Prima Donna Syndrome
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.