Unsettled issues for a software development team

May 5, 2016 12:17 PM

How much back and forth about the nitty-gritty of software development is healthy on a team? Are teams more productive if they spend less time on these issues—or more? Do we know?

A couple of years ago I joined a software development team at a small startup. My career has always been in tech, but the last time I wrote software full time was my first job eight years ago, so I don't have as much perspective about normal team dynamics.

There are a few philosophical issues about software development that always feel like they're open, and discussed repeatedly. The kinds of things you see debated in blog posts and articles. Unit tests or integration tests? Return error values or raise exceptions? Organic Git history or squashed commits? (Only issues that are reflected in the work product. We're not arguing over the best editor or whatever.)

I don't think anybody expects these issues to be 100% settled, and I think everybody's OK with that. They don't interfere with us getting work done. They come up at the times you'd expect them to come up: retrospective meetings, code reviews, lunches. The fact that these issues are still open isn't an obvious, immediate problem.

Lately I've been writing less code myself to fill other roles at the company. As a consequence, these discussions have popped up less often, because I'm usually furthest away from the group average opinion. Now I might get back to writing code full-time, and I'm wondering if I should keep the discussions at this level. Either by simply distancing myself from them; or maybe even staying in my current roles, and away from the day-to-day coding.

I brought this up with my supervisor. He agrees with my assessments about my opinions compared to the groups', and the fact that they've come up less. When I suggested the team might be better off that way, he softly disagreed. He thought the back and forth of opinions made a stronger team.

It got me wondering: Do we actually know anything about this? Are there studies about how teams come together, or don't, on software development practices, and how that affects their output? Failing that, I'd also be happy to hear anecdata from managers and experienced developers about how much these discussions can be healthy, and when they aren't. Thanks in advance.

posted by brett to Work & Money (9 answers total)

How often are you discussing these issues? How heated are the discussions? In some ways, it doesn't matter what the answer is, as long as everyone is doing the same thing (and had adequately considered the alternatives). If you're discussing them every retrospective or code review, or one person always uses exceptions and another always uses return values (and each has their place), that seems like a problem within the team, in that the team is a group of individual programmers doing whatever they want, and not really a team.
posted by JawnBigboote at 12:25 PM on May 5, 2016

For a bit broader perspective on this general topic, I recommend the New York Times article "What Google Learned From Its Quest to Build the Perfect Team".
posted by Dansaman at 12:32 PM on May 5, 2016 [3 favorites]

I think he's half-right. It's an indication of a healthy team that people feel able to raise these kinds of issues and be heard. But I don't think it's healthy if you have to keep revisiting the _same issues_ over and over again! Your team needs a technical authority who can take into account all the relevant factors and make a reasonable policy for the team, and then everybody should be expected to abide by that policy and STFU about it unless they can make a compelling case that something has changed since the issue was decided.

Your team sounds like it has a leadership vacuum in this respect and it's wasting your time. I can't imagine your team is short of more current and productive topics to have healthy design debates about.
posted by emilyw at 12:53 PM on May 5, 2016 [6 favorites]

Unit tests or integration tests? Return error values or raise exceptions? Organic Git history or squashed commits?

1. Both
2. Depends (I'm in the antipattern camp, mostly)
3. Depends

It's a manager's job to set the coding standards. Obvs you guys aren't figuring it out yourselves, and your manager is being weak.

He thought the back and forth of opinions made a stronger team.

Oh, do tell. I can almost guarantee you that he can't back this up with anything but feelings. Since you're the one who gives a shit and are moving toward more managementy stuff, start working on pushing him out and taking his job. I bet he's weak in other ways, too. /rant
posted by rhizome at 12:54 PM on May 5, 2016

Best answer: In my experience, this is only really problematic when these conversations turn into proxy wars about territory, influence, or just between people who don't respect eachother or communicate well. If you have a cohesive team that communicates well, these conflicts actually can boost productivity and efficiency. At least, that's the central thesis of The 5 Dysfunctions of a Team, which is a pretty popular book that discusses this problem (at a broad level, not specifically regarding software - but it's very applicable).
posted by pazazygeek at 1:29 PM on May 5, 2016 [1 favorite]

I think its fine to discuss them whenever, but its also important to have a team or person who can, in the end, say "these are our coding standards" and then everyone follows that.

It will be impossible to find 100% harmony on everything unless the team is insanely small (and probably actually impossible unless the size of the team is 1). And while all of us have Strong Opinions, the reality is most of these things don't matter as much as Getting Stuff Done, in the end. Plenty of companies use Version Control System X instead of Y and are just as successful. Or Tabs instead of Spaces (one of the most successful companies/projects I've worked for used tabs, despite that being a distinctly minority position in the overall software world).

There are some things that matter more (while the exact style of tests don't matter as much, having robust testing is not really optional unless prototyping). But its usually more important that people agree on it and you don't end up with 10 different sub-code-bases with their own design approaches and coding styles.

At my current large company, we debate this stuff on internal lists all the time. But at the end of the day, there are teams that set overall expectations and styles and people follow those. (At a smaller company this might just be the head of engineering or some delegated person saying "This is the One True Way here, for now.")
posted by thefoxgod at 3:21 PM on May 5, 2016 [1 favorite]

It's healthy to be able to easily raise technical issues and have a clear back and forth about why you might choose A over B.

But the issues you list - these are the kind of issues where at some point a decision should be made, given all of the current information, for This Is How We Do It. And absent NEW requirements or arguments - the discussion is left there.

Consistency in your codebase and practices is valuable.
posted by Ashlyth at 6:20 PM on May 5, 2016

emilyw +1

you need a (good) 'software lead'. who can gauge when these issues need to revisited, or put on the shelf for a while. there's more and better 'fights' to have: anyone implementing with LOD in mind? how's DIP?
posted by j_curiouser at 6:31 PM on May 5, 2016

Response by poster: Thanks to everyone who answered. All the perspectives are very helpful. "Weak management" seems to be the most common theme here, and that seems like a fair assessment.

I appreciate the feedback about when this turns bad. It doesn't sound like we're there yet. Discussions don't get heated. Nor do they come up at every code review or retrospective. They just... never get fully resolved. So when a writer and reviewer can't reach their own consensus for a branch, the whole enchilada is fair game for discussion again.

I marked pazazygeek's answer as best, since that book comes closest to the kind of broad study I was hoping to find. I'll definitely track that down. Thanks!
posted by brett at 5:54 PM on May 7, 2016