From: Adam Flinton 

Paul Ranson wrote:
> I don't see a contradiction.
>

"Right tools" means what?

Right politically?
Right financially?
Right for the person suggesting it? Right given existing systems?
Right for future proofing?
Right for the skills base your empoyees already have? Right for the skills
your employees want to learn? Right for the decisions taken by a far off hq
of the company of which your company is but one division?

Most tooling can do most of what is required by most systems. I've done
Java/J2EE & C#/.net & the diffference is....????

Basically you're glueing people to transportable data (as an ML (usually
XML)) fired as text over tcp via some std mechanism (e.g. http) to
something wot either puts stuff into or pulls stuff out of structured
storage (an SQL DB).

Delphi can do that, C++ can do that, Java can do that, C#/.Net can do that,
Python can do that, Perl can do that etc.etc.etc.

So it's never the right tool in the techie sense but always "do we
want to be bound hand & foot to MS"? Or to AIX/*ix? or...or...or
etc." Followed by "what are the costs & risks?" etc.etc.
In there somewhere there will be "I need something which can make me
look good (as a manager" (e.g. tight timescales etc)) vs another
person's "I need something which will look good on the CV & thus I
want to try the new & hot".

The right tool for the task technically might be the wrong tool for the
task financialy or politically or in terms of skills (&/or aspirations
of skills)


etc.

Adam

--- BBBS/NT v4.01 Flag-5