It's not about you

By Adrian Bridgett | 2017-02-02


People aren’t generally selfish on purpose, however, there’s a particular case that I’ve seen several times - especially at startups - which I think deserves highlighting.

The shiny

Anyone who works in the computer industry knows that the rate of change is very high. In the fast-paced world of startups and Internet megacorps, if you aren’t using a tool or language that was just posted on Hacker News last week it seems as if you are out of touch. Woe to anyone who wants to use an old, mature product — that’s almost sounding your death knell.

This is a flawed attitude. Yes, it can be exciting to use shiny new tools, to discover their wonders (and flaws), to write and submit features (and bug fixes/reports). However how much of this is for your sake and how much is for the company that you work for or your team? Oftentimes decisions can be based more upon a desire to use a new tool than knowing the limitations of existing tools and desiring an improved approach.

Maybe you don’t need to use that “OMG my new database is so amazingly fast” product. Perhaps a standard database would work just fine. More importantly that standard database would be working immediately — your colleagues (current and future) probably know how to use it (and the gotchas) already. Moreover, tools and support (for example monitoring, configuration management) often lag substantially behind the product and will take even longer to mature.

The most important reason though, is that whilst there are many many new products and tools out there, most don’t pass infancy. At this point, they become a liability — hindering progress rather than aiding it.


There are certainly good reasons to use new tools - one of the most important being that it keeps people happy and motivated. Learning new approaches and finding their pros/cons is often best done on a real project rather than a toy project.

Decision time

As for many decisions, look towards the future — is the application you are building likely to be around for a while? Is it critical? Should you play safe, or is this a suitable testbed for shaking down new technology that will benefit everyone?

Hindsight is rare, so how can you predict the future? One good indication is whether adoption is increasing or slowing down, is there a growing community. Ask people’s opinion once they are past the initial honeymoon period — are there critical unaddressed problems, or is there a feeling that the project is solving issues quickly and practically.

Overall — think about your colleagues and the company that you work for. Will they thank you for introducing that new tool/language/approach or will you be the person responsible for adding to the workload rather than easing it?


Using a new technology on a core project is not the most sensible place to start. It has a greater impact when there are problems, more people need to be involved in the decision and training people also puts a higher load on the team.

Start with a side-project, something more isolated where a smaller group will be impacted. If things go well these will be advocates for the new approach. It may be that the project is a temporary or prototype project - this has the additional benefit that if it doesn’t work, it’s likely to be thrown away. With the lessons learned from this first implementation, the next implementation will be smoother, cleaner, more maintainable. Effectively “plan to throw one away” (or rewrite it!)