The recurring misguided desire for components
Neil Weber seems to think that the world of tomorrow will be one where we shop for finished components, sprinkle them with business-specific attributes, and off we go with a done system in no time at all. This future has had industry-wide fascination since the beginning of time. I believe it is a false hope.
I concur. It matches my own experience, even though I’ve been in denial for a while.
What made me realize the intractability of this goal was Fact 16 in Robert Glass’ article Facts of Software Engineering Management, which reads:
Reuse-in-the-large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable.
Details on why in the article.
What my experience tells me is this: If your requirements for a given component for any particular project are generally simple, but they’re different from project to project, it’s less work to build simple solutions that do just what you need and nothing else, than to try and build the general component that can just be configured to match your project-specific requirements from project to project. As a rule of thumb, the general component cannot be done, and so you end up with a complex component that still doesn’t do what you need it to do for your next project, and then, because of the complexity of it, it’s more expensive to modify the component than to write something from scratch that does just what you need.
See also facts 17 and 19 in the article above.