Nobody likes to be called a dummy by a dummy.

The myth about using 'the best tool for the job' in IT

I just do not have time to find it, learn it and decide whether it *is* the best tool for the job.

Maybe .net would be the best for a particular project.  how the hell would I know?  Ive never programmed in it.  by the time Ive learnt how to use it sufficiently well to decide that its the best (or that its not) Ive tripled the cost of the project.

maybe ruby on rails is better than python.  I wouldn't know. Ive never used it.

Almost inevitably the best tool forthe job is one of the tools that I already know well.
Almost always they are all sufficient to actually perform the task, differing tools will simply shift the pain points to differing areas of the project.

so, Ive decided to give up trying.  Ill use what I know and just teach myself new stuff as I choose too.

how do you chose the best tool for the job?
Permalink Send private email FullNameRequired 
January 28th, 2006 9:50pm
Using your argument shouldn't you still be writing using the language you used when you first started developing?

Honestly, it's just like anything - if the tool you have suits your needs and you can produce with it, then yes, it's the best tool. But at some point you *should* evaluate other tools, even if only to become familiar enough with them to understand where they work and where they don't...

Philo
Permalink Send private email Philo 
January 28th, 2006 9:57pm
nah.  thats why I said "teach myself new stuff as I choose to."


"But at some point you *should* evaluate other tools, even if only to become familiar enough with them to understand where they work and where they don't... "

agreed.  the point is how?  when?  it takes a surprisingly long time to get past the "hey this is fantastic" thing into the "ah, so this is how it really works?  why dont these 25 stupid things work?  wtf is this buggy piece of crap?  oh, dear god, Ive committed our $100k USD project onto *this*?

I guess my main point is that it takes far too long to 'evaluate' a language.  you cannot usually tell its strengths or weaknesses until youve used for some actual, serious coding.
You cannot believe the whitepapers these days (could you ever?) they are all advertising rubbish.
So its not a matter of simply spending a few days 'evaluating' something, you just end up with an idea of how useful it appears to be after youve used it for a few days...you *still* dont have a clue how badly it will bite once you have a large project written in it.

so how do we evaluate products effectively?
Permalink Send private email FullNameRequired 
January 28th, 2006 10:21pm
I'll take the opportunity to show you what I have just accomplished. I'm creating my own Web Framework, and the biggest drawback is that it does not make use of the most performatic approaches, but on the plus side I have things like this one:

start{|w|
  w[:fu] = fileupload{|f| f.save_to('/tmp') }
  w.pack 'Send a file', :fu
}

This little code, when used in my Web Framework, allows an user to send a file and when I receive it on the server I can choose where I want it saved right in the even of the component. My framework is being built using the components approach that I dig so much. On the other hand, it's a reallu thin layer on what the Web allows by default, so I avoid doing redirects only to clean up the URL address bar, but redirecting is easy enough so I can do it manually if need be.

So, for me, the best tool for the job is the tool that I have chosen coupled with the tools that I have created using it. In hindsight, I can tell you that time flies by me, so the tools that I create will not be public because they need to pay off first. The main advantage of creating my own tools is that I can decide freely when they should be upgraded, if at all, so I'm out of the treadmill of learning the best tool of the week.

For you, I would definitely consider something like Ruby on Rails, because people are hard at work creating tools for Rails all the time, so once you take part of their community, you will enjoy lots of tools for free. But there is a catch: Ruby on Rails is better for Internet sites than for Intranet sites, because many times you will find lots of Windows for servers in Intranets, and Rails works better on Unix systems, including MacOSX.

Between Java and .Net, I prefer .Net.

I can beat Java and .Net in some regards, but they can beat me in lots of ways as well. I'm happy with my trafeoffs. But you should play safer and adopt .Net as an important mainstream tool. I probably will have time for .Net only next year, if ever.
Permalink Lost in a code jungle 
January 28th, 2006 11:16pm
huh?  Im not looking for a tool recommendation.  Ive got tools.  Im simply whinging about the impossibility of actually evaluating new tools within a reasonable timeframe.  ....its almost always simpler/more efficient to simply use whatever you know.
Permalink Send private email FullNameRequired 
January 28th, 2006 11:19pm
You are right about that. (In hindsight).
Permalink Lost in a code jungle 
January 28th, 2006 11:20pm
On the other hand, it's much easier to learn a new tool than to fix the old tool.
Permalink Lost in a code jungle 
January 29th, 2006 12:04am
>> Im simply whinging about the impossibility of actually evaluating new tools within a reasonable timeframe. <<

You've got to be proactive about this stuff.

But of course, it's always the case where the boss walks up and asks "What do you know about X?" where X is the one technology or tool you haven't quite gotten to yet.
Permalink Send private email example 
January 29th, 2006 11:24am
"On the other hand, it's much easier to learn a new tool than to fix the old tool."

I don't think that's really the case.  It reduces to the same argument as refactoring vs. rewriting depending on the old tool that youu need to fix.

To adequately replace the old tool using the new tool, you're probably going to need to learn more than what you would to fix the old tool.

For instance, say you need to fix the way user accounts are created in the old tool (a web CMS).  To do this, you need to learn how the user accounts are managed in the old tool, and fix it accordingly.

If you started using a new tool (some new CMS, or one you wrote yourself), you'd need to learn how user accounts are handled, how pages are created and handled, what the new templating system is, performance constraints, etc etc etc.

It may seem easier at first (and it may be for some cases), but I doubt that it is for most cases.
Permalink Send private email Andrew Hurst 
January 29th, 2006 1:11pm
For example, ASP didn't have OOP and PHP didn't have OOP. If you were to fix that, you would waste lots of time. Even after PHP got OOP, it is still barely used by most PHP folks, due to the legacy and incompatibilities between versions of PHP.

Another example: it's preferrable to use a programming language that has an industrial strength ORM library than to create an ORM solution for your pet language. That is, if you want to use ORM.

Same thing for GUI: it's preferrable to use a programming language that makes that straightforward than to try to fix it for your programming language (PHP is for web sites).

And lastly, if you want to be employed, it's preferrable to use the programming languages that most of the market needs than to waste time with programming languages that aren't as pervasive.

Besides all that, if you have passion for what you do, anything is worth it. Do whatever you like the most. :-)
Permalink Lost in the jungle 
January 29th, 2006 2:30pm

This topic is archived. No further replies will be accepted.

Other topics: January, 2006 Other topics: January, 2006 Recent topics Recent topics