Balance between "right tool for the job" and familiarity in IT projects

Choosing the right tool for the job is a very hard question, specially when you move from the world of theory to the world of production.

In Theory

Quite simple. Always use the best tool for the job, and just learn what you need to.

In Practice

Not only is there the question of your fluency there are a host of other business questions that need to be asked before you can answer this:

• Cost of purchasing the "correct tooling".
• Cost of supporting this - people need to be trained.
• Cost of the learning curve.
• Integration cost with other products ( now and into the future ).

Our Only Goal

The money is paid for results, not for coding.

The Learning Curve

This is a typical learning curve:

It works for programming as well, Although due to technology change it is not an alone curve but a bumpy road.

When you learn programming and some technology, in the “honeymoon” step you get a strong urge to reimplement stuff someone does “better”.
Because you can do it in a month, max 2 months. Much better than people with bigger experience did after spending 1000 - 10000+ hours on some framework/platform.

At some point you notice problems. In the end, your project is either OK for a specific niche (eg: WordPress is not the best platform for 3– 4-page site) or non-maintainable crap. And you have got a deadline.

A possible approach

This isn't really resolvable except as a business question. However, a lot of business questions are made only looking at short-term numbers, which is a mistake with things like this.

Three things to keep in mind as you think about cost and benefit:

• If it's a small or short-term thing, always write it in the familiar tools.
• If it's a big, long-term thing, look at the cost-benefit tradeoff of learning a new tool.
• If you aren't sure, treat it as a short-term thing until you have evidence that it's a long-term thing. Then go and look at the decision again.

People in a hurry tend to short-change the future, but maintenance costs are the lion's share of the costs for any successful system.

Good developers like learning things, and keeping your developers happy is a good long-term investment.

In the end

Experienced programmers will try to deliver good (not perfect) project before deadline and will try to use proper tools for that.
Again, the money is paid for results, not for coding.

The faster you can provide solutions for common problems the faster you can get to interesting stuff where you have to write good, interesting quality code for problems where there are no good enough solutions.

Using common solutions for easy problems makes them easier to maintain for other programmers too.