All That Glisters

Drew McLellan wraps up our 2017 series with a gentle reminder that in a rapidly moving industry, the best technology for the job isnt always the newest. And while Christmas tradition tells us we should follow the bright star, sometimes the answer lies closer to home. Merry Christmas and a happy New Year!

Tradition has it that at this time of year, families gather together, sit, eat and share stories. Its an opportunity for the wisdom of the elders to be passed down to the younger members of the tribe. Tradition also has it that we should chase cheese downhill and dunk the nice lady to prove shes a witch, so maybe lets not put too much stock in that.

Ive been building things on the web professionally for about twenty years, and although the web has changed immeasurably, its probably not changed as much as I have. While I can happily say Im not the young (always right, always arrogant) developer that I once was, unfortunately Im now an approaching-middle-age developer who thinks hes always right and on top of it is extremely pompous. What can you do? Nature has devised this system with the distinct advantage of allowing us to always be right, and only ever wrong in the future or in the past. So lets roll with it.

Increasingly, there seems to be a sense of fatigue within our industry. Just when you think youve got a handle on whatever the latest tool or technology is, something new comes out to replace it. Suddenly you find that youve invested precious time learning something new and its already old hat. The pace of change is so rapid, that new developers dont know where to start, and experienced developers dont know where it ends. With that in mind, heres some fireside thoughts from a pompous old developer, that I hope might bring some Christmas comfort.

Reliable and boring beats shiny and new

There are so many new tools, frameworks, techniques, styles and libraries to learn. You know what? You dont have to use them. Youre not a bad developer if you use Grunt even though others have switched to Gulp or Brunch or Webpack or Banana Sandwich. Its probably misguided to spend lots of project time messing around with build tool fashions when your so last year build tool is already doing what you need.

Just a little reminder that its about 100 times more important what you build than how you build it.

Chris Coyier (@chriscoyier) December 10, 2017

I think it helps if we understand why so many new solutions exist. Most developers are predisposed to enjoy creating new things that improving established systems. Its natural, because its actually much easier and more exciting to create something new that works exactly how you think it should be than to improve an existing, imperfect solution. Improving and refactoring a system is hard, and it takes real chops, much more than just building something new.

The consequence of this is that new tools appear all the time. A developer will get a fresh new idea of how to tackle a problem usually out of dissatisfaction with an existing solution, and figure the best way to implement that idea is to build something new around it. Often, that something new will do the same job as something old that already exists; it will just do it in a different way. Sometimes in a better way. Sometimes, just different.

Thats not to say new tools are bad, and its not bad that they exist. We shouldnt be crushing new ideas, and its not wrong to adopt a new solution over an old one, but you know what? Theres no imperative to switch right away. The next time you hit a pain point with your current solution, or have time to re-evaluate, check out whats new and see how the latest generation of tools and technologies can help. Theres no prize for solving problems you dont have yet, and heading further into the desert in search of water is a survival tactic, not an aspiration.

New is better, but also worse

Software, much like people, is born with a whole lot of potential and not much utility. Newborns both digital and meaty are exciting and cute but they also lead to sleepless nights and pools of vomit.

New technology contains lots of useful new features, but its also more likely to contain bugs and be subject to more rapid change. Jumping on a new framework is great, right until there are API changes and you need to refactor your entire project to be able to update. More mature solutions have a higher weight of existing projects on their shoulders, and so the need to maintain backward compatibility is stronger. Things still move forward, but in a more controlled way.

So how do we balance the need to move technology forward with the need to provide mature and stable solutions for the projects we work on? I think theres a couple of good ways to do that.

Get personal

Use all the new shiny tools on your side-projects, personal projects, seasonal throw-aways and anywhere where the stakes are low. If you know you can patch around problems without much consequence, go for it. Build your personal blog on a CMS that stores data in the woven bark of a silver birch. Find where it breaks. Find where it excels. Find yourself if you like. When it comes to high-stakes projects, youll hopefully have enough experience to know what youre getting into.

Focus on the unique problem

Thats not to say you should never risk using a new technology for real work. Instead, distinguish the areas of your project where a new technology solves a specifically identified, measurable business objective, verses those where it wont.

A brand new web application framework might be fun to use, but are you in the business of solving a web application framework problem? That new web server made of taffeta might increase static file throughput slightly, but are you in the business of serving static assets, or would it be better to just run up nginx and never have to think about that problem again. (Clue: its the nginx one.)

But when it comes to building that live sports interface for keeping fans up to date with the blow-by-blow of the big game, thats where it might make sense to take a risk on an amazing-looking new JavaScript realtime interface framework. Thats the time to run up a breakthrough new message queue server that can deliver jobs to workers via extrasensory perception and keep the score updates flowing instantaneously.

Those are the risks worth taking, as those new technologies have the potential to help you solve your core problems in a markedly improved way. Unproven technology is worth the risk if it solves a specific business objective. If it doesnt, dont make work for yourself - use something mature and stable.

Pick the right tools

Our job as developers is to solve problems using code, and do so in an effective and responsible way. Youve been hired to use your expertise in picking the right tools for the job, and a big part of that is weighing up the risk verse the reward of each part of the system. The best tools for the job might be something cutting edge, but best can also mean most stable, reliable or easy-to-hire-for.

Go out and learn (and create!) new tools and experiment with them. Understand what problems they solve and what the pitfalls are. Use them in production for low-stakes projects to get real experience, and then once you really know their character, then think about using them when the stakes are higher.

The rest of the time? The tools youre using now are solid and proven and you know their capabilities and pitfalls well. They might not always be the fashionable candidate, but they often make for a very solid choice.

About the author

Drew McLellan is lead developer on your favourite content management systems, Perch and Perch Runway. He is Director and Senior Developer at edgeofmyseat.com in Bristol, England, and is formerly Group Lead at the Web Standards Project. When not publishing 24 ways, Drew keeps a personal site covering web development issues and themes, takes photos, tweets a lot and tries to stay upright on his bicycle.

More articles by Drew