The Right Tools For The Job

Greenfield Projects

They normally seem like a pretty good deal. You get to say things to yourself like “if I did that it would be so much better” or “what were they thinking when they wrote this, we’d do much better now”.

It’s a humbling experience to go through that process and come out of the other side having made all the mistakes that you think you’d never make, hit all the walls that you never saw coming and learn all the lessons that generations before you have already learnt exactly the same way.

A Brief Story

By way of setting the scene, and making this post a little more relate-able, let me paint a picture…

Our fantastic team is given the remit to build a new system. Our team consists of two developers (one very experienced with Rails but not much else and another not-so-experienced with anything but very eager to learn), a product owner and a designer/business analyst. A small team but one excited about the prospect of something new and interesting.

The project has to be delivered in an extremely short time-scale, whilst still keeping up with the quality that we’ve developed a reputation for. Maybe in the future it will grow to something huge.

This is a story of choosing the right tools for the job team.

Pick The Tools For The Team

In many situations, other than those of an extreme growth organisation where hiring new people is rapid, we are working as part of a team. To draw a corollary to Conway’s law - I suggest to my future self to choose the tools that reflect the structure of the team.

In our story I might suggest to my future self (in whatever role) to not build a SPA, to not choose Typescript for the whole stack, to not pick GraphQL to aggregate a number of microservices…

I might instead remind myself that 50% of our development effort is from a junior team member that will likely need coaching, that we’ll have to support the app after it’s built, that I should take another look at Ruby Gems, npm or PyPI (insert package manager here) because there’s probably a module that does what I want already, that building a CI/CD pipeline can be a right faff sometimes…

A Lesson To Myself

Now, I don’t mean to say that we should revert to doing the same thing over and over again. Rather, we should judge what tool is best from more than just a technical perspective. Often the engineers in us get too hung up on the best tool to solve the engineering problem, rather than the best tool for delivering the solution.

The hardest part of building great software has always been, for me, growing an outstanding team. This is just another reminder of that such that one day it might become easier.