October 28, 12:35
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.
Challenge by Scott on October 28, 14:14
Good topic, I wonder, in regards to the realm of Content Management (a common enough aspect of web development), what do people think about JSR 170 , where the goal is to design a spec for a standard content repository.
Note, this does not need to be limited to java only!
I'd be interested to hear some opinions!
-scott
Challenge by gabriele on October 28, 15:18
I'm more interested in jsr 168..
Anyway, I do think that component based development can work.
Just, the only place where I saw it working was VB :)
Challenge by Peter Marklund on October 28, 15:26
I think the decision about reuse must be made on a case by case basis. I'm not sure talking about it in general terms helps us much. We all know reuse is sometimes good and sometimes bad, the question is how do you determine which it is? This question can not have a simple or generic answer.
To get more specific, I think reuse of web applications (ala phpBB) makes a lot of sense if your resources are limited. There are quite a few websites out there that simply wouldn't not be able to have a discussion forum if there wasn't for open source software like phpBB. This doesn't mean that a custom written forum couldn't be better, only that it would be prohibitively expensive. I recently set up a calendar website and resused a PHP calendar app. Without such reuse the site would have never happened. There is simply too much UI and calendar logic there for me to implement in a short amount of time.
Challenge by David Heinemeier Hansson on October 28, 15:30
I tend to differentiate between the use of an application, such as phpBB, and the use of components that you put together like lego to build something like phpBB. So basically, I don't think it would be all that valuable to have phpBB's model as something where I could borrow just the concept of User or Post.
There's tremendous value in applications of course. Building everything from the ground up is naturally silly.
Challenge by Morten Krog on October 28, 17:51
Manouvering the commercial component jugle is seriously difficult and you often end up with components that doesn't quite do the stuff you want and you have no way of fixing what is wrong, The worst example I've experienced was a component from nsoftware to do ssl communication. The component seemed to have a problem with living without a windows message pump and generally was not multithread safe.
After 4 weeks spend in work-around-missery we switched to OpenSSL and finished that part of the project in about 3 days.
Components are good for the industry, but having someone charge for every single building block you need is plainly insane. I seriously believe that the two only models that works are the open source/free-as-in-beer and the single providor (aka Microsoft).
Challenge by Jamis Buck on October 28, 19:02
I think you're right, to a point. However, even Rails supports the idea of components. After all, what are the helper methods, but reusable bits of software that developers may "sprinkle" into their applications? To me, whether you implement them as a single method in a helper, or as an object that encapsulates that functionality, the result is the same: a component that may be reused in many different situations.
But as with anything, a concept can be abused. People can (and do) create components where it makes no sense, and where it actually injures their applications.
Challenge by Neil Weber on October 29, 23:18
David,
I wasn't talking about components. I'm not sure why you thought I was. I was talking about full-featured application frameworks as opposed to minimal MVC frameworks. You injected a lot more into my blog entry than I put into it myself.
See http://jroller.com/page/nweber/20041029#more_on_high_level_application
Neil
Challenge by John-Mason P. Shackelford on November 01, 19:55
It's all about the architecture. A well-architected component-oriented solution is a powerful force for change--but like anything, many fall short, many fail.
Consider Eclipse for example. Eclipse is nothing else if not a component system. The actual kernel is tiny, everything is a component--a plug-in. The net result: hundreds of Eclipse-based applications which can interoperate in very useful ways.
Does it take an extradordinary amount of insight to deliver a component oriented architecture on which a community can build? Of course. Does it mean that it can't or won't be done? Of course not.
Challenge by John-Mason P. Shackelford on November 01, 20:02
BTW Scott, I have never read nor coded against JCR-170 and cannot comment on its merits (or lack thereof), but I have been very happy with the open source Magnolia CMS 1.1 which is built on the spec. Magnolia 2.0 just shipped this weekend and may be worth a look if you interested in a successful product which uses the JCR. See http://magnolia.info.
Challenge by on April 01, 0:36
In your free time, check the pages dedicated to...
Challenge by poker rules on June 20, 23:13
In your free time, take a look at some helpful info in the field of poker rules poker rules http://poker-rules.zindagi.us/ .
Challenge by internet casino on June 22, 5:54
You may find it interesting to check some helpful info on internet casino internet casino http://www.scottishtutors.com/internet-casino.html - Tons of interesdting stuff!!!
