I was going to make a fairly short post pointing to Mike's observation of applying different tools and models to a familiar problem. An initial measure of effort and benefit is "code shrink" and that can draw you into the new approach even more.
Then I read Dan Creswell's post also about comparing JMS and Javaspaces...
In general, to measure the true suitability of a technology to a problem one must solve the problem in the appropriate way for each technology we are considering rather than from the single standpoint of a technology we are already familiar with.This is something our group has been working a lot the last few weeks, i.e. the programming models for the tools we are considering. Some are more familiar than others. Also just determining where to start and how to get into a new tool and its model can be challenging. And then in some cases, rewarding when discoveries and insights are made, and you begin to see where things may lead.
By the way, the thought crossed my mind again recently... has "agile" killed "patterns" or did it die on its own? Are "patterns" the best way to present a new programming model? Does anyone really "do" patterns anymore, the way the original movement intended? Or do we just write some text and draw some pictures and call them patterns? Is there any point to the "patterns" idea anymore? I'm not sure either way.
In any case, Mike's and Dan's posts are worth absorbing... it takes some work to get into a new model, and not just repeat the familiar using a new API.
1 comment:
It is common now to give complicated names and obscure meaning of simple solutions.
Before turn on a light do you think about "Push pattern"? Or you just push the button?
By the way, first book on patterns i just found on amazon contains 395 pages. What it is all about?
Post a Comment