In what contexts are your favourite tools and practices NOT a good fit?

If you’re a developer or architect, I bet you have favourite frameworks, services, libraries, patterns, tools and delivery practices that you love recommending to others, either privately to colleagues or online via social media, blog posts, videos or courses.

Now think of a few and consider these questions: Do you know when each of these things you like isn’t a good fit? Can you articulate to whoever is listening to you when they should NOT use the thing you’re telling them about?

This isn’t necessarily an easy question to answer directly because you’ve only experienced what you’ve experienced and you’re happy because it’s worked well for you to date. Plus there are innumerable other contexts in which you’ve had no exposure to.

State your context explicitly

Nevertheless, there is a simple step you can take to make your recommendation much more valuable: qualify any recommendations you make by providing the context in which it worked for you, and let the reader/listener use that to judge how this might be relevant to them. This goes beyond merely mentioning any drawbacks/friction that you encountered (which you should absolutely do also).

Context is a fuzzy thing, so I break it down into the following two categories:

• Application and software system context — what is the technical nature of the use case/problem you’re trying to solve with this thing
• Organisational context — who are the people and company who used this thing or are affected by its use

I find that the application problem context is often (but not always) explained sufficiently whereas the organisational context of the author is very rarely mentioned. Yet it often has a major bearing on whether or how much the advice being provided matters to the reader.

Here are a few prompts to help you better describe your organisational context:

• Was this a one-person side project?
• If not and it’s a professional team context, what’s the size of your engineering team?
• What’s the skillset and experience level of the others in your team?
• Is this a startup, SMB or enterprise?
• Are there other teams in your organisation that the thing you’re describing affects?
• What other companies/project contexts have you used this thing in?

And there may be other more specific adjacent context that may be relevant, such as your dev workflow or your team’s deployment/release process and cadence.

Why is this important?

With so much content being published these days extolling the virtues of a certain tech or practice, the vast majority of authors fail to qualify their’s and their team’s context in which it was successful (I’ve been guilty of this too!).

This can lead to naive/inexperienced engineers seeing this and thinking they should use it as well. There’s a fair chance that what’s right for one person’s side project (or a big enterprise or FAANG giant for that matter) is not right for you or your team. There are very few universal best practices in software delivery.