SCM and Software Integrity

A friend of mine emailed me about using control of /main versus continuous integration. He argued that a team of productive developers would swamp the select few who own /main. This would cause integration errors to pile up and slow the team down. He correctly identified this as a bottleneck. Using Goldratt's Theory of Constraints, bottlenecks limit the productivity of the system. Thus bottlenecks are to be eliminated (either by shifting resources or changing the process) if one hopes to improve productivity.

I used these controls as a way of achieving source code integrity, not that I recommended it. Achieving source code integrity can be achieve various ways. One philosophy is to place controls on /main and establish a process that is rigorously followed. This will work, but will be slower than ideal because of the bottleneck of the control. There might be situations I would favor such controls, but the situations I can think of involve low levels of trust towards the developer (off-shore development for instance).

I favor teamwork. In a functional team, all members share a common goal. A good team has a culture. I agree with McCarthy (see Software for your Head) that the software takes on the properties of the team. To achieve software integrity the team that develops the software should have integrity. In a team of individuals with integrity I expect the team to own their success. So a team like this will have ownership of checking in well written, well tested code. If a team member is unsure of their code I would expect them to seek out a better developer to validate their code before checking it in. In such an environment mistakes will happen, but they will self correct. If you do not trust your team then high levels of productivity are not possible as controls will slow your team down.