Murder on the dev floor: how to cultivate development team harmony

null

Quality dev work is as much about collaboration and teamwork as it is about code. Although you certainly need quiet time for concentration, the development floor should still be a collaborative space – fueled by daily stand-up meetings and code reviews.

Unfortunately, those who work on the dev floor know that it can often feel like a battleground. From changing requirements, to tight deadlines, to code rage, there are many factors that create tension. If unchecked, these difficulties can incite conflict between colleagues, and create a stifling or hostile environment. 

So, how can you answer these issues to promote collaboration and prevent murder on the dev floor? Howard Williams, marketing director at UK based software house Parker Software, explains how to cultivate teamwork harmony, instead of development discord.

Tensions and difficulties

There are three major tension triggers on the development floor. 

1. Hard to keep everyone up to date with progress and current tasks 

At its core, programming is a solitary task, with every developer focused on their own code. So, when you have a big team of programmers, it can be hard to keep everyone updated and in the loop. This can lead to crossed wires and a feeling of being kept in the dark or isolated. In turn, tensions in the dev office increase and teamwork takes a hit – no one feels included in a team. 

2. Hard to be objective about code 

It’s common for programmers to have their own way of coding, and their own views on what makes for good (or bad) code. Style is subjective. There’s almost always a mentality of ‘everyone else’s code sucks’ — it’s completely normal to feel this way. Tensions can form from this outlook, however, when a developer is subjective, unconstructive or overly critical about another developer’s bad code.

3. Hard to hear – and take – criticism of your code

(And for some, it’s hard to give it.) Just being able to identify when there actually is a problem is only half the battle. If problems and issues can be proven objectively, developers need to know how to broach the subject tactfully. It can be difficult to both give and receive feedback, but it’s a must to maintain code quality.   

Keeping colleagues in the loop

For effective teamwork, everyone needs to be kept up to date with what’s being worked on. This is why daily stand-up meetings are imperative. They’re short, sweet, and great for keeping a dev team coordinated. Daily stand-ups are short meetings — usually about 15 minutes long — that act as an opportunity to discuss exactly what’s being worked on and when. 

Most daily stand-ups consist of three main questions for each member: 

  1. What has been achieved or completed since the last meeting?
  2. What is being worked on now?
  3. What, if any, are the obstacles or difficulties impeding progress.

Despite the simplicity of these questions, daily stand-ups serve as more than a status update. They also promote teamwork and collaboration, providing an opportunity for everyone to highlight any obstacles and problems they might have hit. After the stand-up, other developers can collaborate, help solve problems, and support each other’s work.

For successful daily stand-up meetings, teams should:   

  • Stand up – it keeps the meeting short.
  • Address everyone. Stand ups aren’t just for team leaders, they’re to keep everyone updated.
  • Make sure everyone takes part. Every team member should update their colleagues and have an opportunity to voice problems.
  • Not rely on stand-ups alone for team communication. Stand ups are not a time to discuss fixes, have a chinwag, or tell stories. Other meetings and opportunities should be scheduled for this.

Bad code or just different?

Team members need clear ways to tell, objectively, if a colleague’s code isn’t up to snuff. There are two main ways to do this:   

1. Identify viable problems 

A quick way to determine whether existing code needs to be fixed/addressed is by identifying issues that mean the code won’t work. Look for an objective reason as to why the code is ‘bad’ or unsuitable. Such reasons might be that the code is consistently buggy, or that it’s written so inefficiently as to be confusing to read.   

2. Does it fit with the company’s coding standards?   

Another way to determine whether code is ‘bad’, is to compare it against a set of coding standards outlined by the company. Coding standards are like a uniform for your code. They’re useful for ensuring consistency in the final code – and the overall quality of your product.   

Discussing code quality

A brazen approach to addressing coding issues is bound to lead to defensive team members and office conflict. Code reviews are a great way to provide an opportunity for developers to question a colleague’s code, and offer improvements and fixes in a structured setting. 

Code reviews are time set aside for two or more developers to inspect a piece of code. The goal is finding and fixing as many inconsistencies, bugs and vulnerabilities as possible. Done correctly, code reviews promote collaboration and teamwork, give an opportunity to share knowledge, and improve the quality of your code. 

For effective code reviews

1. Keep them little and often. Code reviews should be no more the 400 lines at a time (200 is best). In small chunks, code is easier to work on and can be done as needed — meaning developers aren’t stuck waiting for feedback. 

2. They aren’t personal, so don’t make them that way. When pointing out errors and fixes, refer to the code, not the programmer. For example, ‘this needs to be renamed’ rather than ‘you need to rename this’. 

3. Everyone completes code reviews. A code review is a process that every line of code needs to go through, and that everybody should complete. When code reviews are completed across the dev floor, they improve code quality and feed a sense of camaraderie and equality between programmers. 

When approaching a colleague about their code outside of a code review:   

1. Ask questions – be as ready to learn as you are to teach. There may be a reason behind the madness of your colleague’s code.   

2. Give reasons for your fixes. By being able to explain why a section of code needs fixing, developers are demonstrating that fixes aren’t an attack on a fellow developer – and reduce the chances of defensiveness or conflict. 

Harmony on the development floor 

Team members don’t always need to fully agree. But they should be able to communicate comfortably, collaborate efficiently, and come to a solution — without tensions rising or hostility growing. 

It need not be murder on the dev floor. By embracing teamwork and creating as many opportunities for collaboration as possible, you can prevent the dev floor feeling like a battleground.  

Howard Williams, Marketing Director at Parker Software 

Image Credit: Rawpixel.com / Pixabay