Inexperienced Teams Are Rampant

Inexperienced teams are rampant in our industry was said in InexperienceGeneratesFailure.

Does everyone on Wiki agree?

What are the practical implications for what's said on Wiki about how software should be practised?

Have we talked about this issue enough?

I think not, hence this page. --RichardDrake

I think it is true, but perhaps it would be useful to talk about what is meant by inexperience. One distinction might be between people who don't have a lot of experience in any kind of software environment and people who don't have a lot of experience with the particular set of tools (and related conceptual space) that they need to use for their current projects.

People who are inexperienced in general have always been with us, in every field, and there is usually some kind of apprenticeship period (possibly academic) during which their skills are honed. I think the difference now is in how rapidly the entire software development landscape changes.

As we all know, Wiki-vistors are remarkably adaptable, quickly mastering the skills needed for our increasingly responsible and lucrative tasks. However, not everyone gets up to speed so easily, and with the rapid evolution of tools and deployment environments, not to mention evolving business contexts where people seem to be in an ever-increasing hurry, a lot of people have a hard time keeping up. Many "experienced" developers have not built a lot of software in their current environments, and therefore can't use them to full advantage. It is reasonable to expect that if radically new structural materials were introduced every year, and fell rapidly in cost after their introduction, many buildings would be built out of obsolete materials, or overbuilt or underbuilt using new materials. I'm not sure how this could be avoided.

I think that there are a number of strategies that are used to deal with this problem:

Develop in popular languages and environments.
Stay away from bleeding-edge technology if you don't have a pressing need.
Outsource projects to specialists in a particular technology.
Standardize tools so that there is more internal skills transfer.
Do a lot of training. (but of course this takes time, and as soon as people are trained, they leave, so this is less popular)

--MatthewWilbert

the difference now is in how rapidly the entire software development landscape changes ... many "experienced" developers have not built a lot of software in their current environments

Among other things you've brilliantly captured one of the biggest reasons behind what I've called SoftwareAgeism. Any ideas on how we deal with that aspect? Does it matter?

--RichardDrake

InexperienceGeneratesFailure leads off with I consult across the US. I'm often asked to consult on projects when they are already in trouble.

This would seem to indicate a biased sample. Are projects that aren't already in trouble calling in that comment's author? Is he also seeing projects that are healthy? Is it fair to generalize on this basis? --DaveSmith

There are four main classes of project in my experience:

those that engage outside help from the start
those that are considered successful or low risk enough not to require outside help
those that are in trouble and managers have the security, wisdom, humility, guts and budget to admit that they need help and bring in one or more outsiders
those that are in trouble, often deep trouble, but one or more of the five necessary ingredients in (3) are missing.

That fairly complex picture is itself a gross simplification of course. But my hunch is that because so many projects go straight from (2) to (4) the bias is the other way than you suggest. --RichardDrake

Regretably, projects of type 4 seem to be the most common. I have never worked on a project where a consultant was brought in to add expertise. Lots of contractors to fill swivel chairs but never to help straighten things out.

Is that because they get shot when they open their mouths? It may be a hangover from the eighties, but corporates are very quick to expel perceived dissent.
Messengers of bad news have never been popular. That's just human nature, not the 80's. I myself try to find ways to indirectly bring up issues, such as asking questions in a way that does not sound like criticism.

I think a bigger problem is that not much value is assigned to experience. Hiring managers seem to think that experienced people are less up-to-date on new techniques (or fads, or are more cynical about new stuff), have less energy, expect too much pay, don't tolerate long hours, etc.

WhyIsExperienceUnderValued? in our industry?

Explanation 1: See InexperiencedManagersAreRampant

Some of the gist I got from InexperienceGeneratesFailure was that the team was inexperienced in the processes that they were supposed to use. If you have experience in the problem/business domain and the with the tools, you'd still be lost while you try to figure out the process the team is (supposed to be) using. This could also be a result of InexperiencedManagersAreRampant. --DaveParker

One of the types of experience is working together. Seven new and four experienced developers plus a manager or two working on a project have just met each other on the first day of the project. The initial assignments will be wrong and given to the wrong people. The wrong people will be given the job of design, and so the design will not be good. Take those same dozen people a year or two later and put them on another project together. The initial, crucial decisions will be much better. The improvement will be much larger than the simple one or two years of experience would seem to indicate. The estimates will be more accurate. All this is very hard for corporations to do. People get promoted, quit and have babies. Teams with good self-knowledge can put the weaker members on jobs they can do usefully. I testify to all this from experience and observation.