This post originated from an RSS feed registered with Ruby Buzz
by David Heinemeier Hansson.
Original Post: The recurring misguided desire for components
Feed Title: Loud Thinking
Feed URL: http://feeds.feedburner.com/LoudThinking
Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp
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.
At RubyConf '04, Brad Cox (co-designer of Objective-C) blamed the apparent stand-still of the software industry on the lack of a viable commercial platform for components. If only it was easy to resell your Bill of Materials class, we could design it once and for all and merely "reuse".
In all humbleness, I think this is yet another software mirage. Software is not like hardware, high-level components can't be reduced to interchangeable IC's. Software is a collection of design decisions and where that cut should be made, which decisions we should bother with and which we shouldn't, is ever fluctuating.
The components dream is in many ways similar to the aspirations of model-driven architecture. Programming is a soon to be lost art of craftmanship, move over for industrialization!
Only it never really works out that way, does it? 4GL's and CASE tools have had their rise and fall. The point is that when you already know what you're going to build, such as a Bills of Materials system, then it's likely that you can just buy a finished system and alter it slightly. It's obvious that once you drastically reduce the problem space, pre-made applications are more likely to be a Good Enough fit.
But to think that we can reduce the problem space for information systems in general, to make it fit our existing components, is where I spot the disconnect. When I think back on the systems I've done, I can't come up with many good candidates for classes I could have carried all the way through and merely configured.
At least not on the business level. Rails is a great example of how infrastructure, that which is below our domain models, can and should be standardized. But design decisions can not follow this road.
Of course, I'm merely replaying my version of what many of the great thinkers in software had done long ago. The solution is not to embody repeating business problems in components, but to look for patterns. Gather, synthesize, and describe the forces, challenges, and good solutions that other people have come up with.
This sums up my vision for Rails as well. The border at which new functionality is accepted or rejected lies at the brink of the business domain. I don't believe that user management, access control, discussion boards, or Bill of Materials classes make for good component candidates.
I fully recognize that this might very well just be a limitation of my intellect and that wiser men truly has found the holy grail of software. But just label me skeptical on this one.
Previous Topic
