Hi Chris,

I have not read the referenced article. From the words below I infer that the primary reason for failure is 'choosing the technology based on the skills of the developers'.
Frankly, I would like to know how this was determined...

I feel that most shops plan all of their development based on the set(s) of tools/skills they have on hand and if they determine that the objective cannot be accomplished with those then they either can the project or plan to acquire/grow the necessary skills. It would be a sad shop indeed that got very far along with a project only to 'learn' that their chosen tool(s) were not up to the job (I hear it happens but that is clearly bad management).

On the other hand, planning on "having developers aquire skills in the right technology..." suggests that they would be 'learning' the tool/skill as the project moved along. Now this has got to be a recipe for disaster (at worst) and a poor application at best. Think of your *first* dBase/FP/VFP/whatever program in any language compared to one done after a coupla years experience with that language. I know I blush and cringe when I look at my 'firsts' even though I have been in programming for over 25 years.

I don't know how people conduct studies along these lines. It looks to me to be a part of that vast right-wing conspiracy to convince all DEVELOPERS that they must be proficient in several languages in order to be successful in the future. My contention is that in fact only a handful of developers can retain high proficiency in more than one language at a time - as you delve more deeply into one any prior ones lose ground. If nothing else the learned efficiencies of the earlier become blurred by the same aspects of the new language. Also, one loses 'touch' with the prior languages, which also progress in capabilities as you are concentrating your efforts on learning/keeping up-to-date on the newer chosen language. Soon, at best, the skills of the older language are "frozen" at the level where you last had it as your chosen primary language.

"The right tool for the job" is being blown way out of proportion, in my humble opinion, and when it is applicable then a far wiser choice to me is to buy/rent the skills of people HIGHLY qualified in the particular area. To expect existing staff to learn them on the job can only result in an inferior application, as I see it.

Computers and programming offered something that no other business tool could - the ability to be shaped and moulded to meet the DIFFERENT needs of any business. Any serious and genuine programming language aimed at the business environment (I'm not so sure that VB is aimed there) has these capabilities. We should not be so quick to accept some popular "wisdom" (in this case, "The right tool for the job") and apply it to our own PERSONAL choices. Doing so will, I feel strongly, just water down the quality of the products we are capable of producing.

Cheers,

Jim N


>>> One of the factors in deciding is what are the skills of your developers.
>>
>>Intelligent Enterprise had an article last month that lists choosing technology based on the skills of the developers vs. having developers aquire skills in the right technology for the job as one of the primary reasons for software project failure.
>
>That seems odd to me. I can see it if you're talking about a group of Cobol progrmmers trying to implement an n-tier application, but if you have a group of good Delphi programmers, then justifying VB or VFP is much more difficult.