Principle Of Least Efficiency

"Of all the viable products competing for a given market niche, all other things being equal, the one which maximizes paid labor (and thus generates the largest pool of trained experts and the greatest demand for new trainees) will become dominant."

-- JayOsako (as a special case of the "WorseIsBetter" Principle)

It must be understood that this is an observation about market forces, not about the actions of any one player or cabal. To repeat an important point: evolutionary systems adapt to local maxima, not to any absolute 'fitness' or 'superiority'. Part of the local maximum in the software industry is being able to field an adequate number of experts capable of supporting the system. If a system doesn't give a payoff (which is usually but not necessarily economic), then no one will be induced to become an expert on it; and if a system has little need for experts, then there will be less incentive to become an expert, leading to a ViciousCircle until the number of experts drops below the point necessary to support the product.

It can be noted that there are natural limits to this. If the quality of the product drops below acceptability, then no number of experts can make it viable without the product being either improved or replaced. Also, the number of experts for a given system is itself limited by supply and demand: too many 'experts' (or too few actual experts in a field of claimants) will lead to supply exceeding demand, dropping paid labor below the point of being an incentive for newcomers to the field. This was seen in the period around 199-2001, when the number of MCSEs exploded suddenly, making the certification worthless - or at least, even less valuable than it was before. In that case, both the number of MCSEs and the quality of their expertise were factors, but that is usually a factor anyway.

For any who would see this as a SilverBulletConspiracy, I would direct them to consider HanlonsRazor in this regard (or consult their PinealGland).

MotazKaySaad? wrote, on news:comp.software-eng :

I do not have a practical experience in software development and would like to pose the following issue in Object Oriented System Analysis AndDesign? (OOSAD) approach.

The OOSAD & UnifiedModelingLanguage focus on problem (Class) separation: Control, Entity, Boundary. But RapidApplicationDevelopment (RAD) tools like MS VisualStudio DotNet, Delphi, etc do not make this easy to manage when writing or implementing software applications. The use wizards in database connectivity, transaction, and transaction forms ?! . Do you think that using RAD tool is a good idea in OOSAD?!

You might be detecting the "VendorLockIn" phenomenon.

Maaaaybe these guys draw the same OOSAD & UML diagrams as you envision, but then maaaaybe they draw them with slightly different motivations and intentions than yours... --PhlIp

See

CategoryBusiness