Wednesday, November 16, 2016

A Pull Request Ping Pong

There's a schema that needs doing. Nothing special. Just names of things. Allowed values. Defaults. And from my past experiences, doing this badly early on is a source of many bad things when multiple systems are supposed to communicate (and won't) or when someone realizes that it should be called something different. I tend to come with this feedback from the testing angle, so better get on it early on to avoid ripple effects.

We meet and agree this works needs doing and we will do it as everything, with pull requests. Just change it for the better, each of us individually. Nothing happens, so I bring us together again to agree on principles of naming, organizing and formatting and we walk out with some rules I can act on, and agreement that I wouldn't but that everyone else ("programmers") would. We agree also on a timeframe.

Timeframe passes and half of the people have done changes. No one has really done changes we agreed to be applicable throughout the schema. So with deadline, I both remind people (and stuff happens) and volunteer to do some of the consistency and documentation related work on it.

I get sucked into the fascinating process of pull requests. A lot of them, on a short timeframe. And a lot of them having a lot of discussion. I experience the wait time. The rework. The ping-pong. The silently undone work that no one volunteers to do as it might be rejected as there isn't a principle on those yet.

Like for naming of fields that have a time numeric value to include the information if it is this time milliseconds, seconds, minutes or  hours. Like for knowing exactly what each value does to ensure the names communicate the right things through several systems. Like checking default values for consistency when they are spread around in a few files that none finds immediately their own.  There's a lot of hope of "someone else's work".

With the time we used on the ping-pong, we could have met together and done a lot of this work. So I wonder where the idea of the excellence of pull requests for this comes from. And all I can think of is the idea of being able to work alone. Pull requests are appearance of collaboration when there is also real collaboration: pairing or mobbing.

I think of this the next time someone tells me mobbing is ineffective. There's still so much of harmonization work that none volunteered for today, with the hope that someone else will deal with it. Or, time will take care of it. When there's more than this one place of dependency, it's clear it will no longer change. It's now or hard. And I prefer getting things done.

A great reminder from a friend:



2 comments:

  1. Just guessing here, but when I imagine mobbing around naming conventions, I picture a huge waste of time debating over the best way to communicate a meaning - I see such a thing when we try to name a configuration parameter during a design meeting\review (since we all agreed that the initial name isn't good enough, every person comes up with a different name, and we waste a lot of time trying to choose between two (or more) equally good names - if any of those was in the first suggestion, no one would have said anything, but since they are both only proposals, we feel the need to discuss them in length.
    Do you have any positive experience of mobbing for such a task?

    ReplyDelete
    Replies
    1. The approach we've been using is concrete examples and always changing for the better. Just use one, and if people have better, then change it.
      With mobbing, the way of handling proposals has been to do both and then choose. It's surprising how people are ready to discuss something to the bitter end, but often no longer care when it already there.

      And when they do care, in a group after implementing they get to see have a quick discussion while making the choice.

      I believe that this is one of the problems created by separation that melts away. Facilitation may be good to help maintain a productive atmosphere.

      Delete