Bad things happen when developers don't communicate

I was recently reminded of the danger of leaving less-experienced software developers alone to create new functionality in a technical area where they have no prior experience. For instance, suppose you have one or more good but less-experienced developers, and you ask them to work in a technical where they have no prior experience. These aren't totally inexperienced developers; they may each have at least five years experience. Given that their are other people on the team with experience in this area, how do you think this should be handled? Choices include:

• Assign the task, and leave them alone to do what they think is best to solve the problem.
• Have the experienced people create a little architecture (framework) for the less-experienced people.
• Have a kickoff meeting where the experienced people share their knowledge with the less-experienced developers.

Unfortunately the answer in this case is that we chose option one, and trusted the less-experienced developers to do the right thing to come up with a solution. And instead of them asking questions of the experienced people, they asked people they were either comfortable working with, or they sat next to. (I don't know why they did what they did, I am just speculating here.) So, while we have a little of this new functionality working today, I learned today that the underlying architecture may need to be completely rewritten.

I'd have to list the following items as root causes of failure in this area:

• The project managers did not force the less-experienced developers to consult with the experienced developers. (Yes, they trusted the less-experienced developers, but now they have been burned for that trust.)
• For one reason or another the less-experienced developers did not choose to consult with the experienced developers. (EQ versus IQ?)
• By working in geographically separated cubicles (a few rooms apart) as opposed to a common open space, the experienced developers were not able to overhear the less-experienced developers, and offer their advice, because they did not know about the approach that was taken until today.
• Because developers don't regularly attend morning stand-up meetings to discuss their work this opportunity for communication was also missed.

In cases like this I think the best thing you can do is have the experienced developers lay the groundwork (architecture) for the other team members, then serve as a mentor for the other developers. Alternatively, the experienced developers should at least be consulted for "best practices" in a given area, and then the other developers can handle all of the code and architecture.

This story makes me understand anal-retentive project managers. It's their butt that's on the line if the project fails, and they've just trusted people that they now know they can't trust. As a PM you get burned too many times by people you thought you could trust, and pretty soon you don't trust anyone. It's a fine line to walk.