You should use this framework!

So you're sat in an office and you're chatting to a colleague, or maybe you're just in on a conversation, and someone turns to you and says "We should use X".

Maybe 'X' is a framework like React, or a new CSS preprocessor. "We should use X" is a topic that comes up a lot in Front End development; it's opinionated and often controversial. Chairing these types of conversations needs to be done effectively to avoid things getting heated and become divisive.

"We should use X" is usually met with questions from others like "Why?", or "What problem will it solve?". Off-the-cuff justifications are often contrived, reasons like 'productivity', correctness or a vague notion of 'better-ness' are given.

While these reasons are usually the wrong ones, the suggestion can – frustratingly – be a good one; it just needed to be put across in the right way.

Developers are very good at recognising new techs that are 'better' – at least on the surface. After all, it is part of our tradecraft to be able to intuit whether a technology is 'better' or 'worse', but it can be difficult to get under the skin of why something is better or 'right'.

It's important to understand that 'X' – whatever X may be – is designed to solve specific and real problem. React is great for SPAs, and CSS preprocessors are great for managing CSS. They are great tools if you were looking to write a big SPA, but they are naturally less good at other things.

Often, when a developer is saying "We should use X", they're actually saying "we need a way if doing this thing. X does this thing well". While "we should use X" can be controversial, it's also a golden opportunity for a team to question its way of doing this thing so it can improve itself.

Fundamentally, the statement "we should use X" is implying a change in the way the team is working. Sometimes we can let our hearts rule our heads, especially if we feel things do not need changing.

Changing how we work as part of building a stronger team

It's important to accept and realise that change can be challenging before, during, and even afterwards. It requires perseverance and is a process. Realising successful change in a team can be broadly broken into these steps.

  1. Sharing: someone does a 'show and tell' about an idea/tech they've seen.
  2. Learning: Interested team members get hands on with the tech, either through workshops or in production.
  3. Consensus: people figure out the way they like to use the tech/execute the idea.
  4. Using: a 'critical-mass' of people will adopt the approach or it won't catch on and it will die.

Sometimes there are additional things that managers/tech leads need to consider – especially changes that involve learning curves or coordinated effort. This can be called the 'pragmatic business case' and common considerations for tech leads/managers are things like:

  • Effort of Adoption: how much effort will it take to adopt this approach – can everyone do it, how do we get there?
  • Hiring Barrier: is a bar being set for hiring by adopting this approach? How will this affect recruitment and dept. growth?
  • Measurable Results: can we measure improvement? What are the outcomes of succesful adoption?

Big or fundamental changes need to be signalled to executive team members. Broadly there are two approaches depending on how measurable the results may be.

  1. Measurable: 'The team are going to do X and it will improve Y by Z'.
  2. Not measurable: 'We've introduced X and it's great'

'We should use X'

Next time someone in your team says 'We should use X' how will you respond?

  • What does it do?
  • How does it help the team?
  • Are there other options we should consider at the same time?
  • Do we have a pragmatic business case? If not, how do we get there?
  • How should we share this with everyone?