“I’ve often thought that software developers were akin to Magpies, birds notorious for stealing shiny items to decorate their complex nests. Like Magpies, software developers are unusually smart and curious creatures, almost by definition. But we are too easily distracted by shiny new toys and playthings.”

—Jeff Atwood, co-founder of Stack Overflow

I think many developers ignore this observation because “Taking this reasoning to its reduction ad absurdum would mean picking Java and then trying to implement a website without using anything else at all. That would be crazy. You need some means to add things to your toolbox.”

”It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it.” —Dan McKinley

We all know someone who jumped from tool to tool and eventually settled somewhere. Whether it’s Java, PHP, Cobol, or (in the case of Neomind) Ruby, finding tools you love to solve a particular problem and sticking with them can lead to a depth of understanding familiarity that completely changes the game. I believe this happens to developers when they get tired of the endless churn of new technologies, and as they start to care more about maintainability.

I’m not arguing that Ruby on Rails is the best tool for every job or that it’s so good everyone should stop inventing new things. On the contrary, I love that people are always experimenting, and I love playing with their experiments. But it would be unprofessional and irresponsible to use every shiny new thing on the types of long-lived assets most people are building.

Why is it unprofessional and irresponsible to use shiny new technology?

Many new tools and frameworks implement sweeping changes after their initial versions, making the upgrade path virtually a rewrite from scratch. A new fad replaces others and fizzles out. Marketing sites, special seasonal initiatives, or one-off applications that serve a limited need have lifespans measured in months. On projects like these, longevity and maintainability don’t play a role in the decision-making process, and developers are free to experiment with whatever new tech they choose.

Most of the projects we see have lifespans measured in years, and yet what is the decision-making process for choosing the platform? Projects governed by the tech-fashion-trend of the day.

Using new/unproven technologies on projects like these would be an irresponsible waste of other people’s money. Failing to consider the lifespan and maintenance needs of the project when choosing a framework would be nothing short of unprofessional (and as someone who uses Zoolander memes in his blogposts, I know a thing or two about professionalism). Yet, many developers make their technology choices purely from what will be the most fun for them. Bored developers find a little “Resume Driven Development” hard to resist.

Even worse, many managers allow this kind of decision-making to “keep the developers happy” and hopefully reduce turnover costs. Many times, the developers only stay a little longer, and there’s a trail of disjointed, unrelated, hard-to-maintain experiments left in their wake.

Choosing a framework whose longevity and maturity reflect your application’s likely lifespan and needs is an important consideration. There are no guarantees, but choosing an immature platform with a small or disengaged community can be a costly, unprofessional mistake.

“Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.” Also Dan McKinley.