Getting Programmers To Agree
Programmers are on-par with politicians when it comes to fiercely debating and rarely reaching agreement — we argue about everything. Getting programmers to agree and be productive together is probably the hardest problem in software development.
Which programming language shall we use? Is SQL or NoSQL best? What is the one true version control strategy we must use? Should the name of this class be a noun or verb? Or should that class actually be 3 smaller classes?!
Debate is fine. A range of opinions is healthy. Even a bit of friction now and then can be productive. But, too often, for developers, decision making brings out the worst in us. We refuse to accept that our opinion is not the right one, and we won’t let it go.
With each of us having a diverse wealth of experiences, preferences and opinions on the subjective art of software development, is it even realistic to expect healthy debate and unanimously-accepted decision making in a team?
Yes it is. It is possible to have a passionate team of developers, with a diverse range of strongly-held opinions, and absolutely it is possible for them to work harmoniously and productively. But how?
What Happens When They Don’t?
Before looking at some examples of teams that do work well, let’s enjoy a few stories about dysfunctional development teams who couldn’t work out a way to be happy and productive together.
See if you recognise any of these…
Never Ending Debate
One story I’ve seen played out at a few organisation is one I call the never ending debate. This story involves a team of developers who struggle to work together and struggle even more to reach shared agreement.
I have known single discussions rage on for weeks over, quite honestly, extremely trivial matters.
Each developer refuses to back-down. Refuses to accept that their proposal will not be accepted. And they keep pushing it. Simultaneously, the harmony in the team is slowly diminishing as the issue creates more and more friction, and becomes more and more personal.
Typically, the never ending debate story is about people who will rarely compromise. Usually, it’s not one debate, but many frequent debates where an amicable solution cannot be reached. Arguing is their modus operandi.
It sometimes feels like putting a group of developers together is never going to result in a productive team, like they are inherently incompatible with each other. But I have seen these kind of teams recover what appears to be a lost cause. You’ll see some of my suggestions shortly.
Loudest Mouth Wins
Another story I’ve seen a couple of times, inverse to the previous story, is the loudest mouth wins. In this story, there isn’t a team of fiery, uncompromising developers, but usually a single big personality who dictates. This big personality is sometimes the designated team leader, but not always.
Invariably, what I’ve experienced is that the big personality crushes the motivation of the other people in the team. The big ego makes all the decisions, whilst the others feel worthless. They’re always getting their ideas shut down and made to feel like they are inadequate.
Being non confrontational, the team members start to develop a grudge and resent the big, dominating personality. They lose their desire to suggest ideas and improvement, and simply fall into the habit of being told what to do and how they will do it.
In reality, this is traditional command-and-control micro-management. And in terms of decision making, it does actually work, since the big ego making all of the decisions has no-one to disagree with. But I think this is a poor strategy for creating a high-performing software development team.
You can be successful with a loud mouth in your team if the rest of the team enjoy following instructions and being micro-managed. But it’s wrong to believe you are forced to choose between having a passionate team of developers who all like to contribute ideas, and a team who can make decisions together. You can have both.
The Phantom Developer
One other story I’ve seen in a few teams is one I call the phantom developer. Each developer tries to pretend other developer(s) in the team are not really there. They lack the confidence to confront each other about work matters, so instead try to find ways to avoid working together.
Usually, the developers will try to take ownership of certain parts of the system. They’ll do everything they can to avoid collaborating or touching each others code.
Fundamentally, the problem is of different styles. One may be a fan of OO whilst the other is an FP die hard, for example. But instead of working together to find a common approach, they each do things their own way. And the longer each goes off in their own direction, the greater the tension that builds up.
As the split-personality codebase grows, the chances increase that developers will have to work on parts that another developer wrote, or they will need to combine modules. That’s usually when the bomb goes off and the fallout commences. On top of the social pain, there is now the big maintenance burden of a wildly-inconsistent codebase.
Phantom developers are usually the opposite of big egos. They tend to be non-confrontational, but a bit too non-confrontational. Later, you will see why I believe that a gentle leader’s touch can remedy the phantom developer problem.
Passionate and Productive: How To Achieve Both
As well as being part of teams that struggled to make decisions and work together, I’ve also been part of good teams where people could get along and debate their ideas constructively. Without doubt, the latter teams were far more enjoyable to be part of and were unquestionably more productive.
Here is the best advice I can offer to create an environment in your team where debate is healthy and people are encouraged to share their ideas.
Build On Shared Values
A team needs enough commonality in their beliefs of software development to be productive together, in my experience. They need to share a solid foundation of core beliefs, so that even when they disagree about specific decisions, they still agree with the goals and direction.
I am passionate about continuous delivery, for example. I could not work with people who are content to deploy once per-month, who are happy to spend lots of time on manual testing, and who have no desire to fix these things when there is an obvious business benefit.
I would not be able to continually defy my principles — to continually accept decisions opposed to my core belief that continuous delivery is a huge business enabler, cost reducer and motivation multiplier (unless there was a compelling business or technical reason). My motivation, productivity and value to the team would be well below my potential.
But it wouldn’t negatively affect my contribution to the team if we used a different continuous integration tool or we had a WIP limit of 3 when I preferred 2. As long as I know that I am working with people who aspire to the same goals, and have the same beliefs of how we can get there, I think I can be happy and productive.
Importantly, I believe this way of thinking characterises the best teams I have seen. Their shared values help them to build trust in each other’s opinions.
And Then Shared Practices
Sometimes values can themselves be open to wide-ranging interpretations, and a team must also agree on practices.
TDD, mandatory code reviews, pair programming, developers being responsible for automated tests. These are some examples of highly-divisive practices. Even when a team shares the belief of continuous delivery, individuals may passionately disagree with some of these practices. Consequently, they may still struggle to work harmoniously.
Let’s take the example of pair programming. Highly polarising, extremely contentious, and no real evidence to prove or disprove its effectiveness. This is a recent classic in the world of religious programmer debates.
If some members of a team are passionate in their hatred of pair programming, they won’t be able to work in an organisation where pair programming is believed to be an important part of the culture that allows them to achieve continuous delivery.
This is why, when building a team, I think it’s crucial to hire a bunch of people compatible with each other rather than just hiring the best developers you can find and hoping they will gel together.
Set Standards Early
If developers are going to have debates about naming things, frameworks and testing strategies, I wholeheartedly recommend you tackle these problems as early as possible. Avoid being phantom developers and letting the pain build up.
There will be some debates and friction, but don’t wait until you have a monolithic split-personality codebase with a tonne of different conventions in it. Have the debates early, kiss and make up, and settle into a rhythm of working consistently.
You don’t need to remove all freedom from the team, but consistency on the big issues is important. How will you test? How will you name things? Try createing a one page document with some general conventions on it, and then apply these conventions as the objective criteria for code review.
Code review and pair programming are great ways to help promote consistency through the team, so I fully encourage you to find ways of making them work in your team.
Have A Decision Making Process
Sometimes, it is actually arguments about the specifics, which cause disruption in the team. I’ve seen developers on the brink of brawling over which frameworks to use, or which design pattern is best. In these situations, a team benefits from having a clear decision making process.
There are many ways to make decisions collectively, and I’m no expert on politics. I do believe, though, in two fundamental characteristics of a decision making process: everyone has an opportunity to present their views; there is a clear point when the decision has been made and the debate is over.
One approach I like is to let people have a debate for around 10 minutes. If it gets a bit tense, that is okay, as long as it’s not personal. After 10 minutes, discussions usually start going round in circles which is a good point to use a more structured approach.
I then recommend letting everyone present their case to the team. They have 5, 10, however many minutes to explain why their opinion is the right one. The team then votes and majority wins. At this point, the debate is over and everyone agrees to move forward with the team decision.
Every situation is unique, so there needs to be some flexibility in the process. As long as people know they have a voice, and when they have to stop using that voice and accept the team’s decision, then I believe you are on the right path.
You Must Be Prepared To Compromise
One skill, one that I believe is essential for software developers who want to thrive in a self-organising environment, is the art of compromise. Knowing when to push an opinion, and conversely, knowing when to let go of one.
I strongly dislike the word “should” to specify assertions in unit tests. A number years ago, I used to take every opportunity to be passive aggressive about my team’s choice to use it. But that behaviour benefited no-one. It was a personality flaw that got the better of me.
In the past few years, though, I’ve learned to live with small, inconsequential decisions like using “should” instead of “must”. I’d rather have a consistent codebase where we all follow the same patterns. I much prefer the feeling of having a happy team to the hollow victory of winning arguments.
But there are so many other benefits, too.
People are less likely to think of me as an opinionated colleague who is difficult to work with and won’t back down. Hopefully, they will know that when I am strongly in favour of an opinion, it is because I believe it is genuinely the best decision for the team, and not just me wanting to have my own way.
And it makes me more adaptable. I can join a new team who have a tonne of conventions and preferences that aren’t to my personal liking, and I have the reassurance that I am capable of settling in to their ways of working.
I’m not advocating that software developers should be less passionate. Nor am I suggesting that compromise is always the right thing. But looking back on my career so far, some of the best all-round people I’ve worked with managed to be full of enthusiasm and willing to compromise on subjective matters.
We can all look to these people for inspiration, and there’s no reason we cannot become one of them ourselves.
A Leader’s Touch
Sometimes a team looks dysfunctional and in total chaos. You think there is no way they can work together. But that’s not always true. Sometimes, it just needs a calming leader who can gently bring them together.
In the story of the phantom developer, a leader who was strong enough to confront the other developers but respectful enough not to overpower them could have helped them reach some common agreement of how to work together. The leader could have reminded them of their shared values and worked with them to set some conventions.
In the story of the never ending debate, the leader could have been the person who gently reminded the team of their decision making process and guided them into reaching consensus.
And it’s a leader’s responsibility to help the big egos fit into the team or tell management to get rid of them.
Not every team needs a designated leader. Many teams flourish without one. But lacking a leader’s touch or a charismatic personality, teams can quickly become dysfunctional.
