Bee,
Do you think having a team of unexperienced programmers who communicate well is better than having a team of very experienced programmers who don't communicate properly?
The way I see it, inexperience is not a barrier to success - but failure to properly communicate is almost always fatal. You can NEVER allow your situation to devolve into an adversarial situation, which is exactly what you get when you stop talking.
Do software projects really need experienced managers in IT or any managers will do?
Mr. Boehm's book was quite thorough. One of the more important factors was that every project should have an experienced lead designer and/or programmer. This person's experience would, by communication and osmosis, become available to the junior staff.
This is why many "how to" books on management use the concept of frequent reviews of progress at a detailed level. (Yes, this sounds like being a micro-manager, but I'm talking about low-level, single-project management. See my earlier comments about low-level micro-managers.)
If your junior staff gets
gently nudged in the right direction by your senior team leader, you can expect good things to happen. For this reason, your team leader must have reasonable interpersonal skills. An arrogant, know-it-all team lead is a project killer.
In many cases, Mr. Boehm suggested that the effect of more or less experience was relatively minor. With an experienced leader, having a less experienced staff was usually just a 15% difference in flow times. Having a team with NO experience, top OR bottom, was a lot more expensive, at least 30% if not more. In fact, there are several places where experience counts and they are all different in effect.
- Know the hardware (if you are directly interacting with it).
- Know the operating system (so you can make good system calls)
- Know the language you are using
- Know the subject matter (i.e. if it is an engineering project, don't hire accountants.)
- Know corporate or departmental methodology
Just remember that "knowledge gravity" applies here. I.e. knowledge flows down from the top. So if your top guy is a know-nothing, you are already in deepest doo-doo. Because crap ALSO flows down from the top. You NEVER EVER give an unknown quantity the lead on any major, corporate-crucial project. Make your unknowns 2nd in command for their first project and let the experienced leaders evaluate the newbie.
In the final analysis, a company that hires a non-IT person to manage an IT shop can effectively kiss off that department UNLESS: The new person has experience in a DIFFERENT type of engineering applied-esearch situation.
My original comparison was "assembly-line" mentaliity vs. "research-project" mentality. Whether the person is specifically IT-cognizant is less important than that they recognize the extreme volatility of an IT development schedule. I once worked for an electronics engineer who also ran an IT development shop as his second hat. He wasn't bad because he knew it was development work, not a cut-and-dry (cut-and-paste?) operation, that was slowing our progress on our big project. So though he wasn't up on the terminology, he understood the nature of the beast.
If your managers are like one of my Marketing Engineers from about thirty years ago, they all think that programming is just "a test and a branch." If you ever hear a Marketeer say that, do the world a favor and KILL that S.O.B. before he further pollutes the gene pool. Or give him some haughtily delivered rejoinder - like "Yes, but you pay me because I know WHICH test and WHICH branch to use."
