From the author of

From the author of

The parody
"How to Crash and Burn Your Java Project"
was fun, but probably all too close to home for some developers. After all,
it's hard to see the funny side when you're in a
death march
on a dysfunctional project. The survival strategies in this article won't
solve all of your problems, but applied early enough they should prevent a major
crash and burn.

Balance the Team

Java projects need developers who understand object-oriented (OO) design.
Running an experience-light team of cheap, fresh out of school, Java
wannabe programmers is obviously not a good idea, but the opposite, too
experience-heavy team is not the solution either.

Project teams need to be balanced. While it's okay to be
experience-heavy, most organizations find it hard enough to recruit experienced
developers, so projects rarely suffer from an overdose of experience. Ideally,
you want an even split among experienced, intermediate, and beginner
developers.

Up to a third of the team should be enthusiastic beginners. Aside from the
obvious advantage that they're cheaper, enthusiastic beginners can energize
the rest of the team with their thirst for knowledge. They also keep the rest of
the team honest when it comes to writing maintainable code; after all,
they're likely to be studying the
Refactoring
book in their spare time.

The middle third of the team should be good intermediate developers. They
should have been part of a team that has successfully delivered a Java
application. To my way of thinking, anyone who hasn't delivered and then
stuck around to support the release for a while is still a beginner. Developers
gain experience by seeing a project through from the start to production use,
and until developers have that experience it's safer to think of them as
beginners. I agree that this might seem a little unfair, but I'm more
interested in improving the chances of success than I am of being unfair to a
developer who has two years of Java experience on projects that failed to
deliver.

The rest of the team should be made up of experienced developers. They must
have delivered and supported at least three significant applications, two of
which should have been written in Java. I require three applications because the
first is done as a beginner, the second as an intermediate, so it's only on
the third project that a developer is really ready to take on a lot of delivery
responsibility.