>>The real trick [as always] is in the planning - assessing the market and translating those requirements to a simple, understandable plan that will deliver the project on schedule and on budget!
>>
>>I agree, that's crucial. However your last phrase is the kicker. "on schedule and on budget"
>>
>>[1] How to come up with a reliable estimate of time (and hence costs) for developing a software application
>>[2] How to ensure that the actual development is on schedul
>
>I have to do it all the time - but I have been doing it a long time. After gobs of full cycle projects - my deliverable success is about 90%. Sometimes - the due date is determined by the baby<g> - IOW - The client needs it to be "by this date".
>
>Experienced prospects can tell by light in the eyes weather or not the person they are talking to can deliver.
>
>A lot of prospects confuse programmer - coder skill sets with full cycle project management and designer/developer skill sets. I thought at this point in the digital age, that prospects would have the skills to figure who can do it and who can't. But a lot of the purchasing suits operate under a the old political philosophy: "If you don't know what you're doing, pretend you know". Unfortunately they tend to purchase from those that have a like-minded short sightedness.
>
>I have heard about a project where the client's purchase/project guy, despite the obvious fact the project was behind by almost a year, kept giving manageent techno-geek speak to cover his decision. Eventually, the team that was hired to do it - had to confess they were in over their head - and quit!
>
>I have heard an attorney say: Programmers are like painters, implying that one programmer was like any other. Thats not the truth - there are painters that do excellent work and there are those that sloppy.
>
>estimates as high as 85-90%) of all major software projects are late and over budget.
>That tells me that only 15% of those buying or doing project work are earning their pay. Agencies like this - they populate a project with just out of school - or techno-geek-speak experts - and they get an endless summer of billables.
>
>If someone could come up with a reliable way to objectively assess how much has been done, and how much remains to be done, and to estimate the times required to the levels of accuracy that are achievable in other industries, there is a fortune waiting for them
>
>Point me too it!!!!
>
>There are people that can do that - but incompetent purchasing managers tend to hire incompetent project leaders. I [and others] have methods to build a delivery estimate. It requires experience. I form a basic outline of the all requirements in the first hour of the initial "project" meeting. I have an idea of the data structures, the modules to maintain those structures and the modules that transact with those structures. But I spent 9 mos in a specialized school that did nothing but FLOWCHARTS. I think structures and structured programming are missing in todays environment. The truth is that agencies make more money and managers insure their position by having less than adequate engineers working on projects.
>
>The guy who invented netscape calls this The Crappy Guy Syndrome. He explained it this way: Managers tend to hire people less competent than they are as a means of protecting their status (job security). If they hire through an agency they can blame it on them. Many programmers are using

Mmmm, I'm not sure...
There's another consideration that a manager has to deal with. Failing employees will drag down the manager with them. A manager knows that a successful team will also bring personal success.
Take also into account that the manager has another role. Why would a manager, who mainly talks to customers and other managers, feel threatened by technical employees who mainly write specs and code?

But maybe you were referring to the relationship between THE senior LEAD developer and the other developers, who are often times hired by the lead developer?! In that case, the Crappy Guy Syndrome may be at work indeed.

But I like your initial statement that it must be possible to form a team of solely GOOD programmers that IS successful. In sports they try it all the time.