Friday, June 16, 2006
Strive for progress observability
One of the key features of iterative development processes is the ability to make the work in progress observable. Clearly, different roles have different needs, and different level of observability are required: for a contractor milestones are important on the agreed deadline and day-by-day evolution shouldn’t matter, a team leader should instead look also for daily changes to better guess directions every developer is moving on.
During “pure development” phase, I normally ask my team to commit their job on the CVS or Subversion repository as soon as possible, at least on a daily basis, but I realized that this might sound odd to some of them. Personally, I can’t find any good reason (in this phase, at least) not to commit any code which is slightly better than the previous version. If the code won’t compile or breaks some test, then it’s a good choice not to share it, but that’s the only reason. By postponing a commit you’re just putting a slightly risky area (merging and integration) a bit closer to the deadline, giving a minor trouble a chance to become bigger.
During early stages, I sometimes try to enforce “competitive access” to shared resources: if more than one developer is accessing the same file, then the first one to commit pays a smaller integration burden. This might sound pretty naïve (and I’d never use this style for the whole development process…) but it’s normally part of a “shock therapy” to rapidly establish team mechanics, if there are new team members or developers still stuck with MS SourceSafe bad habits. Once everybody is confident they can get along with the versioning policy, the team can switch to a less aggressive style.
Don’t forget that even if you switch to a more coordinated policy, you might still need the practice for emergency recovery, production bugs, night fix and all of those situation which can become nightmares if you add complexity on top of a mess. If you are skilled for troubled water, then you’re less likely to get panicked.
Tags: Agile, Software Configuration Management, Project Management