Software development efforts continue to fail because of poor implementation of more than adequate technology. The software industry creates new tools and languages to solve problems that don’t exist while developers and engineers rant about complexity, “difficult to implement” technologies, and deficient paradigms. The problem is the quality of the people, not the quality of the technology.
During my years as a consultant, I have repeatedly worked on teams or was sent in to support a product that was improperly installed, configured, and/or used. The bunker cry of each failing project is always the same: “this product sucks”. Examples have ranged from overriding the default configuration of the product with custom scripts which were unnecessary if the product configuration guide had been given a cursory read (which eventually led to an inability to perform other standard configuration changes or product upgrades without much difficulty and increased unsupported customization of the configuration), to abuse of a non-standard capability within a product to avoid learning the technology for which the product was built.
The answer to these problems is to get the right people for the technology or to accept that getting such people is not possible and to change the technology to one that can be adequately staffed. Every change in technology costs an organization money in the loss of reuse of existing components and the loss of investment in training on the previous technology. The gains from migration must be weighed against what is lost. I’ve watched projects migrate to an open-source product under the concept that they avoid the cost of product licensing while the cost of migration would pay for the product licensing for the next 5,000 years.
Technology sprawl is not the answer.