Thursday, December 10, 2015

Birds and statues - or phrases to keep to yourself

There's a conflict emerging - on merge conflicts and how to deal with them.

Sometimes I wonder why I care - I'm a tester after all. But I do care, since the quality of the code matters to what kind of results we can achieve as a team with help of testing. I care enough to nurture an atmosphere where refactoring is not only allowed, it is encouraged. We're not trying to stop change, we're trying to flow with change. And we've been relatively good at that, doing continuous delivery without test automation. Clean code is easier to work with. And in most cases, we have pretty similar idea what is clean code.

It seems there's an exception to every rule. My exception comes in the form of different beliefs. There's one (with 20+ years of experience) who believes that the things I've taught to believe about team work and clean code are incorrect. That we should find ways of working with code by one individual only to avoid merge conflicts - and human conflicts that result in changing the status quo.

When I suggest we wouldn't have a conflict if we paired or mobbed, I'm not being helpful. So I try not to mention that while I still think of that - a lot.

When I suggest we would have less conflict if we had smaller methods and that refactoring would be a good idea, I'm told we should stop refactoring all in all and always just write new code. We can just add fresh branches, leaving the old that worked there as is, still working. And that code style and cleanliness is just an opinion anyway.

When I suggest doing smaller increments that can be released to contain the conflicts, I get a shrug. And I get a bunch of others saying how good a strategy that is, but also remarks on how this area is just different.

When I ask what we could do, I hear we could just work on different areas completely, in isolation. To avoid merge conflicts - and human conflicts. It's worked for decades, what would be different now?

There's a phrase that I managed to keep to myself that I've mentioned before this all became urgent and pressing: be the bird, not the statue. I heard this at Agile 2015 from Arlo Belshee and Llewellyn Falco. The one who stays put is the one who gets hurt in merge conflicts in the modern software development. But saying that right now might be again not helpful.  But I think of that - a lot. And I admire the conflict-averse other developers, who increase their birdlike features in all three dimensions of how they deal with the shared code, leaving one statue there to realize implications later.





2 comments:

  1. I think I didn't quite follow the whole birds and statues thing, but I have a question about something that caught my eye - You mentioned that the answer you get to "what can we do" is "try to work on separate areas of the code", and I wonder - can you afford it?
    More specifically - can you, personally afford this? and can you, as a team afford this?
    Personally - you have mentioned that you have ~9 developers and one tester on your team, can you be there to provide your unique perspective and manage the context-switches around 9 individual initiatives?
    As a team - can you afford having most of the team oblivious to what is done by any single developer? In my team, which is sitting in the same office (or the next-door at most, still within shout range), we struggle with making sure enough people are familiar with each piece of code that is written, so that if someone is sick, or has decided to leave the company, we don't have a huge gap to cover. I can only imagine it will get worse with teams that do a lot of remote-work.

    ReplyDelete
    Replies
    1. Birds shit on the statues. In configuration management, the one who does not move gets most trouble. Small changes in small scope are very helpful.

      And on "try to work on separate areas of code" - we can afford many things. We can afford leaving people create something that never gets out into production too. It just does not make sense.

      Personally, this different person easily eats up my attention, you're right about that. Then again, I can have other developers on him, rewriting pretty much everything before I need to see it. So nothing needs to be personal.

      As a team, if there's anyone oblivious about this it is the developer delivering different code. We redo it (refactor it, remove a lot of ingenious solutions to barely get it to work). We assign other developers to take lead of the code in the area. And that is right now why this is again more urgent: we're breaking down the silo where conflict-aversion and full individual freedom are only rationale's that it should ever exist.

      It's an interesting sample of how much a team can compensate for an individual, and how out of control the business representatives can be with software being "magic".

      Delete