If I had to choose the most common trait among software developers, it’s probably the tendency to be amusingly irrational when choosing the tools for a task. The decision always seems to be heavily skewed in favor of personal preferences, a desire to try out a new shiny hammer or, slightly more rarely, to hold on to the old trusty at almost any cost.
Many are the times I have seen developers grab an entirely new toolkit, framework, or language and dive head first into a non-trivial task. In a world where technologies appear and are discarded at rather breakneck pace, one can almost forgive giving in to temptation. But when it happens without properly considering the alternatives, it is unprofessional, risky, and not something that belongs outside of private one-man projects.
But alas, the result is usually that a lot time is spent on trial-and-error and the result is usually ripe for consolidation, refactoring or even reimplementation. Most developers when nearing the end of a project really wish they could send back the wisdom and knowledge they’ve gained to their past selves. Some programmers even wish they could start over, while others cannot wait to attack the next problem with their new found wisdom.
Unfortunately very often, the programmer will decide the solution to the problems faced during development is to switch out the hammer for a new much shinier one, that will definitely get the next job done with much less hassle. And more fun!
The excitement and sheer joy of using new hammer is what keeps many programmers happy and productive. It’s not all bad, and sometimes the gains from adding something new or using a new technology can really make a project. But there is a risk, and not managing that risk responsibly is a problem.
Forcing someone to use yesterday’s tool is difficult, and I don’t think it works if the person hasn’t accepted that picking up new hammers might not always be a good idea. Not to mention that hype, a shiny demo and the lure of a silver bullet is often an easy sell to the stakeholders of a project. But I would advise anyone on the client side of a software development project to be extremely skeptical of the technological choices made by the development side. Do not trust developers to have the same priorities as you, and don’t expect them to be aware of their bias.
To an experienced developer should come the realization that new tools, technologies, frameworks and platforms need to be approached with caution and respect. Learn them in your spare time, use them in small projects before the big ones, learn from the mistakes of others. Don’t trust those who wish to sell your their successes. And if you need to bring in consultants to use a new technology, it’s probably too early, and you risk paying someone else to learn from your mistakes.
I didn’t really touch upon the grumps who really hate using a new tool or who fervently reject certain types of technology or platform due to personal bias or past experience. The advice is really the same. Use small projects and your spare time to learn the pros and cons of new hammers. Someone who knows how to appreciate a good tool, should appreciate the value of a well-stocked toolbox even more. Be skeptical of your own technological preferences, and re-evaluate them at regular intervals. Learn new things even if you don’t trust them to better than the old things. Acquire new tools.
That’s what we should aim at: Growing our toolbox. No matter where in the spectrum we are when it comes to adopting new technologies or tools, we should approach them as tools to add to our collection. Do not expect a silver bullet. Do not expect that you can throw away your existing tools. Accept that sometimes the best tool isn’t the one you’d like to use.
Last but not least, to those who want to turn everything into a tool or technology-building exercise, and I think every programmer has been there at some point, please exercise some restraint as well. Programmers often try to morph the task at hand into something they would rather do, or they become so enamored of their ability to craft generic and flexible solutions, that they spend too much time on crafting an amazing technological foundation – forgetting the actual product and not delivering on that. That’s a potentially much more damaging variation of the shiny hammer syndrome.