It never ceases to amaze me how many development teams work as a group from a single development server. That is, multiple developers sharing a workspace for a single application, staged on a single development server.
Although this type of environment is very simple to set up, and caters wonderfully for ad hoc and sporadic development by multiple parties, it nevertheless spells disaster for more serious code management.
I gave a talk, "Taming the Code" at webDU 2007 in Sydney last March. In a room of about 100 people over half the audience worked on a single, shared development environment. Even fewer attendees used any sort of version control. It’s an all too common problem in the web development community.
Having helped several teams move to a more distributed and managed development environment I’ve found the most popular reasons for resistance include:
- sheer apathy; change means learning something new increased cost
- developers will require a more sophisticated workstation and associated software loss of efficiency
- involving all these additional steps and reconciling developers efforts takes far longer than working direct on the shared server
- But perhaps the biggest barrier to action is lack of confidence; how should things be set up? what products should we be using? where do we start? Those teams that want to make the move are often hamstrung by indecision — if you want to change the whole development team's approach you hardly want to head off in the wrong direction.
Even if you’re really keen, the literature is nearly all too technical, too academic, too… impractical. The emphasis is on system capabilities, and solving complex problems. The assumption is you already know what you are doing.
All Software Configuration Management (SCM) books are aimed at desktop and enterprise level software solutions. Nothing really caters for teams that want the benefits of code management but still need to retain the agility required for web development.
What information do people need to help them make the move?