[motter]

I agree with the main conclusion here, but it's a stretch to reduce technology choices to a simple "new or not" dichotomy.

Let's say you're writing a new web service in Java, because it has features aplenty and is also the language your team is most familiar with. You're confident the JVM is a platform you want to build on.

Now you need to:

1. Choose a set of libraries or a framework. Do you go for Spring or Java EE, or for something newer like Play or Dropwizard?

2. Choose a build tool. Maven? Ant? Gradle? Maybe we'll write some scala, so SBT?

3. Choose tools for deployment, config management, etc.

4. A database.

5. And so on.

All of these tools have different trade-offs. There are so many trade-offs that I don't think blog post comparisons (or whatever) cut it. And so you have the "magpies" who try and figure out some of these trade-offs for themselves by experimentation. (That is what, in my opinion, hack days and 20% time are for, not your new production system.)

But don't listen to me, we wrote our new web service in Go ;)

More seriously, it was a major decision and I couldn't possibly write a few hundred words on my blog to justify it. I may write a few thousand, though.

[kyle_t]

"All of these tools have different trade-offs. There are so many trade-offs that simple blog post comparisons don't cut it. And so you have the "magpies" who try and figure out some of these trade-offs for themselves by experimentation. (That is what, in my opinion, hack days and 20% time are for, not your new production system.)"

Absolutely. Someone has to be the designated pseudo-magpie in order to architect the stack. Doing so effectively though requires a dev who can look past the buzzwords and elevator pitches to really get to the core of it. Essentially they have to be magpie and anti-magpie at the same time. Does this new technology really offer me any benefit or is it the same end result wrapped in new clothing?

[pron]

Right. Because like it or not, justified or not, when new tools are developed, old ones are abandoned. Sometimes if you stay with what you believe is the tried and true, you end up having trouble supporting new features.

This is true mostly for libraries, though. If you switch your main programming language more often than once a decade then you're either a true magpie or you just don't know how to pick them.