Cole Porter wrote a song all programmers should embrace...
One thing we programmers don't do enough, or at least don't discuss enough, is experimentation. Every application we write is somewhat new, perhaps completely new. Something about the technology is usually new as well. Often something about the team itself is new.Experiment. Make it your motto day and night. Experiment And it will lead you to the light. The apple on the top of the tree Is never too high to achieve, So take an example from Eve, Experiment. Be curious, Though interfering friends may frown. Get furious At each attempt to hold you down. If this advice you always employ The future can offer you infinite joy And merriment, Experiment And you'll see
Every new venture or project can be aided by thinking about your assumptions and your hypotheses about how it might succeed and what might interfere. Each of these, in various ways, can be handled by treating it as an "experiment" of sorts -- how do you propose to address these hypotheses? What if something turns out to be other than what you expected?
Of course your sponsors may be annoyed at best if they believe all you are doing is "playing". These experiments have to be time-boxed, well chosen to address risk and value to the sponsor, and well structured to make sense of the results.
I recently responded to just such a situation someone is grappling with on the REST yahoo group... I quote myself...
Re: REST and ESB
> present one of three alternatives:
> 1) REST + centralized ESB (e.g. Mule)
> 2) REST + centralized Message Queue / Mediator (e.g. ActiveMQ)
> 3) REST + decentralized, "powerful" end-points
A big advantage of the REST/HTTP approach is that many kinds of
systems can participate. Reducing to one of these three appears to be
an artificial constraint. Why make that decision now, up-front?
> (5) have short "time to deployment"
> (4) Performance is a issue
> (4) is a point-to-point service
> (3) is data-centric service
> (3) need multiple adapters
> (3) can have high concurrency of users
> (2) have long running processes
> (2) needs high level of Compensation
> (2) needs integration with legacy data
> (2) have complex business logic
> (1) needs low latency
You may want to choose one or two of your services, one or more of
your "REST + X" options, and two or three of your capabilities listed
here, and conduct time-boxed experiments, say over the next six weeks,
to investigate the most important or promising combinations of these.
These time-boxed experiments will provide a much greater wealth of
real experience than you would obtain trying to make a decision
through discussions on this list alone. Even though there are
incredibly bright people on this list, your own experience over six
weeks will tell you more than you could possibly imagine by sitting
and thinking alone.
I've been a programmer for a while. This approach has served me well going back into the early 1980s, when there were not nearly so many books, blogs, and frameworks to rely on as today. I often long for those days just for that reason.
Around 1985 when I was a programmer at Data General working on internal tools for designing electronics, another group was developing this new thing (at least to us) -- a "relational database" -- could we use it for electronic circuit data? We conducted an experiment. Of course we found the implementation was fairly slow, even for those days. We also found our first occurrence of the "O/R mapping" problem.
In 1995 I wrote in the usenet comp.object list...
>At the risk of agreeing with RCM, I say integrate early and
>often--just make sure you do so from the bottom layer up.
I look at risk management in two dimensions:
1. The risk of providing the correct behavior.
2. The risk of any technology used to implement those behaviors.
A. Prioritize the known required behaviors.
B. Prioritize the proposed technologies according to which behaviors
they will be applied and the certainty of the use of the technology.
C. Prioritize resources (people, tools, money, etc.) toward both risks
as best meets the overall risk:
i. Prioritize toward verticle prototypes of the most important
behaviors. Make them as independent of any specific technologies
ii. Prioritize toward horizontal prototypes of the most critical
technologies: i.e. the ones used in the most important behaviors
that are also the least understood.
iii. As horizontal prototypes prove the technologies, plug them into
the verticle prototypes to prove their combination.
Therefore, experiment. Wisely.