Limit developers per branch



The woes of developing software at my current company continue. My current piece of work is to take a panel off a window and put it into it's own separate window because the "Product Management" team like the idea of dragging that information around the screen and possibly minimising it. Whilst testing my feature I realise I need to give my user a new permission. I head over to the user admin section of the application only to discover I can't "simply" make any changes because the dialog has white text on a white background. I ask my boss what's up and he says "Oh another team are working on that. They're overhauling our app with the new Windows 8 Metro look and feel". So when will it be fixed? When they've done the whole change. In the meantime, I have to cast my mind back and rack my memory to try and figure which one of these checkboxes in an array of 20 gives me the permission I want. It slows me down. It slows everyone on the team down.

Our system is littered with flaws and half work courtesy of other devs. Almost every other day a tester reports a bug and fails my work, only to discover that it's nothing to do with me. The real cause of this painful situation is our work-flow. Me, one of around 40 developers I think, does their work in Visual Studio and shelves it. It gets code reviewed by a peer who checks it in to the main branch and then the system is built and ready for the testers to do their thing. Then every so often we branch from the main branch and it becomes our 8.1 release or whatever.

Bugs happen, that's why we have testing. Also, yes, things should reasonable be expected to work when we check them in as well.. but checking work in to the main branch shared by the whole development team before it's tested? That's insane. Checking in half features, or things you've broke but plan to fix by the end of the sprint? Force everyone to put up with that breakage? That's just wrong. Thus, we need to limit the number of developers per branch.

The solution of course are team branches and/or feature branches. You do your coding in isolation, get it tested in isolation and share it with the rest afterwards. Developers shouldn't have to build on broken code. This team unfortunately isn't at the point of continuous integration but we have a daily build and smoke tests and for the most part of this month they have been broken. The number of regressions is high as testers and other development members say "that's not my bug" or "just ignore that breakage for now"..If developers don't know what should and shouldn't work and start turning a blind eye to bugs they assume were pre-existing or someone else's responsibility you end up with a crappy and buggy product and a horrible day to day dev environment.

There are several things bothering me about my current company and top of the list is the use of TFS. As Agile dictates a team should be between 4-9 developers, I want to claim that a single branch in a version control product should not be getting commits from more than 9 developers in quick succession without those commits being thoroughly tested by proper QA folk.

In open source stuff you often get a choice of how recent do you want your software? The choices are stable, unstable, testing and experimental. I would argue if you've got 40 developers continuously sending in untested changes to a branch you're somewhere deep into experimental and the gap between experimental and stable is quite big. Since we don't have the same phrases to move things to stable where code changes are limited, we merely get more untested changes slapped on the end of experimental still.

I'm sure most of you would agree the bigger the development team the more infrastructure you need. Either that, or you need those developers to be in self-contained Agile teams (which is a form of infrastructure). Here's the truth: More infrastructure does not mean locking down who can and cannot make a branch in TFS. It means that more work is distributed and possibly more processes are needed, perhaps specific to the business. TFS does not give the developers the flexibility to tackle this challenge. It becomes a barrier to it.

It's a question of scale. The more work and commits flying around the more scalable tools you need and processes in place. Distributed version control systems are the only way to get the flexibility developers need to organise a large team and to work without impacting each other and stepping on each other's toes all the time. Distributed tools like git and Hg allow developers to create and delete small cheap branches and to manage commits with a more freedom. Merge conflicts can be solved easily and safely once. Any company with more than 10 developers needs to be using a distributed solution that's powerful enough to allowing testing of the work at various stages. Everyone committing untested work to the end of a single branch is just ludicrous. It's like a swarm of bees and managing bugs becomes an unnecessarily huge overhead.

If we can't move to distributed version control we at least need team level branches to localise breakages. We can't be expected to build on the broken. It's the only way forward. Distributed version control is flexibility for a large company, not a market place bizarre they can't control. They should be adopting them rather than claim that TFS is enterprise because it's centralised.