From: S2 <x@...>
Date: 2008-07-06T23:26:29+09:00
Subject: Re: from ruby/RoR to Java (framework unknown) :(

Eleanor McHugh wrote:

> a task which
> experience tells us he could have completed in three weeks with Ruby.
> Unfortunately they were a Visual C++ house so he spent 6+ months doing
> it that way.

This is one of the disadvantages when you are forced to use a tool that is
not the best for the job, but are there advantages as well?
On "Choose the Right Software Method for the Job" on www.agiledata.org,
Scott Ambler makes a good point:

But what about developing a data warehouse as compared to an online ordering
system?  Your organization might do both of these things, and now suddenly
it isn’t so easy for you to fairly judge the situation.  Senior management
might want these two projects to follow the same method to make it easier
to manage, measure, and compare their entire portfolio of projects.  IT
support groups, such as enterprise architecture and enterprise
administration, want to work with project teams in a consistent manner
using a consistent set of artifacts.  Similarly project stakeholders who
are involved with several IT projects will want to follow a consistent
approach with each team.  Your human resources department doesn’t have the
budget to train and educate people in every single IT method and technique.
It is clear that there is significant pressure to follow a single method
within your organization. 
What do you do?  The sixth philosophy (Sweet spot. You should actively
strive to find the “sweet spot” for any issue, avoiding the black and white
extremes to find the gray that works best for your overall situation.) of
the Agile Data method advises you to find the sweet spot between extremes. 
In this case the extremes are following a single method for all IT projects
and following a different method for every single project.  The sweet spot
may be found by adopting a handful of methods that between them cover the
majority of project types within your organization.  Each project team
would choose one and then tailor it to meet their specific needs.  In
organizations that tackle one type of project, as is common in smaller
firms and in specialized consulting firms, the size of the handful may in
fact be one method. A large organization, such as a financial institution,
telecommunication company, or government agency, that tackles a wide range
of project types will discover that they require several methods.

So. There you go. Java for everyone.