Tuesday, 8. April 2008 14:52
Yesterday I had an interesting discussion (although I thought there should be none) about wether or not to open a branch for developing a new part in the application with a small team. It all comes done to: if we branch we have a lot more overhead… Hmm, in my opinion: WRONG!
So what were the main points I heard in the discussion:
- If we develop on the branch every developer directly gets and (indirectly meant) recognizes our changes to the code.
- Changes to our model (yes we are working with model driven parts) are not so hard to be merged.
- There is a communication overhead because the team needs to communicate about some fixes, implementations, etc.
So, really here are my answers to these points:
Answer to #1: I already put the “indirectly meant” in brackets because it is an assumption that everyone on the team not only gets all the changes but also recognizes them. Yes, we need to define merge points or directly inform people about hard or intense changes. But really is this a bad thing? Inform someone about something that’s not a geegaw? I believe this is how communication in your team should work by default!
Answer to #2: Well, see at answer #1. If there are parts in your code, that are hard to merge (and no other way to handle it), wouldn’t you inform your teammates as soon as possible? How do you know someone hasn’t got a small branch on his own? So using lock-mechanisms of your scm and inform your team about your changes is inevitable anyway. (Why are DailyScrums so useful, he?)
Answer to #3: (My favorite one) You are forced to have an active communication in your team and that causes a communicationoverhead?? To say it the hard way: You just don’t want to think about the overhead you have if you are not communicatedirectly, you just have it afterwards! Ok, let us revise this a bit: Yep, active communication takes a bit time. I am really sure about this. But let’s take a look at the otherway around: What if you have a passive communication? How big is your overhead at the time you realisedthat some communication was missing? If you have phrases like “But I had checked that change in, didn’t you recognised that?” or “I was sure everyone understood this like me?” or “Oh I did the same thing yesterday…”You really have more overhead in cleaning these things up than having it clarified directly.
It takes some discipline for your team to commit to active communication. But for me discipline is not a negative thing. We have to be very disciplined every day as a developer, check in often, test often, test the right thing, check our requirements, even fill out our timesheets and burn down our work progress…Is all that a bad thing? Really not, it helps us to see more clearly how our work goes and if we are walking the right way… So every effort you put into this, at the end of the day you will earn more time than you lose. Now back to the example of branching. You have to merge frequently, you have to communicate very often and directly, but what is your benefit about it? Well much less effort on merging the result when work is done. Much less effort on doing thingstwice because people have to communicate before starting work. Much higher bus number in your team because the team is closely in touch with each other… Try to improve active communication, do not try to avoid it!