How Not To Get Burned By Your Next Java Project
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.