Working on a Shared Development Server is Bad
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?
Comments
Gary Gilbert on 23-Jul-07 10:09 PM
Shared Dev Server Stinks!
Geoff, You are absolutely right, we have two shared servers where we work and I have to say it really stinks! When someone is working with DLL's or Java components and trying to configure them correctly the server may get rebooted 10 times in a single day! I, and a couple others have tried to convince Senior Management to switch to workstation centric development but the issue is always on the bottom line. When will the realize that 10 developers sitting idle waiting for the server to come back up is way more costly to the company than investing the time to make the switch?
Pete on 23-Jul-07 10:10 PM
But WHY is a shared development server bad?
You talk about the difficulty in getting some teams to switch to dedicated workstations for their dev environment, but don't really say why a shared development server is bad. Our shop has a multiserver installation of CF for the developers, with separate root directories; I can't think of a compelling reason to switch from that.
Ron Alexander on 24-Jul-07 03:03 AM
RE: But...
@Gary: Hear Hear! Same situation where I work. It is very difficult to sit idle when another programmer goofs and even harder to sit idle when it is my goof fouling other programmers' day. @Pete: You probably missed Gary's post. Shared dev servers usually result in a time loss due to other programmers crashing the server. Also shared dev makes it hard to test different server configs. If you are doing pretty vanilla apps probably not a big deal for you. The value added piece of the above post would be the version control (you didn't mention having it). Using a version control + automated build AND TESTING system is instant savings. The initial cost in terms of hardware/software/learning curve is very cheap for a SVN+Ant setup and works wonderfully with ColdFusion. Do you CFEclipse?
Geoff Bowers on 24-Jul-07 08:58 AM
Why move? Version Control
The whole reason for moving away from shared environments is version control. http://blog.daemon.com.au/go/blog-post/decentralised-development-approach-and-version-control