It depends on your organisational context

When discussing choices for techs or software delivery approaches, “it depends” is almost always spoken. The situational context is key. There are very few blanket best practices in software engineering that are universally true, and those who spout such dogmas the loudest are often those with the least exposure to the different contexts in which software is delivered.

Alex DeBrie’s excellent recent article on the many context-specific considerations for using GraphQL, DynamoDB, and Single-table Design together illustrates these nuances perfectly. (Count the occurrences of “depend” 🙂 ).

Yet “it depends” still feels kinda unsatisfactory for the engineers among us who like to box off things in our head as “solved problems” or “the right way to do X”, or at least have a rule of thumb along the lines of “If X, then do Y”.

How can we break down “context” to help us ask the right questions to come up with better-qualified recommendations for approaches/rules of thumb/default starting points for a given situation?

When I run Serverless Application Roadmap sessions with clients about to embark on building a new app using serverless, we start with a questionnaire aimed at getting a better understanding of the client’s context. This questionnaire is split into two high-level sections:

1. Application Context — Feature and non-functional requirements for the product being built
2. Organisational Context — Details on the client organisation delivering the software, the market in which they operate and what their capabilities and constraints are

In my experience, the application context is where most discussions seem to focus, yet understanding the organisational context is crucial to making the best decisions.

Before I introduced more rigour into my consulting approach, I’d made the mistake on a couple of occasions of underweighting the client’s organisational context by recommending a process or technology to them which, with hindsight, they didn’t have the capability to be successful with or which ended up as more of a hindrance than a help. And similarly, I’m regularly frustrated seeing (mainly enterprise-focused) cloud experts broadly advocating approaches without qualification that I know just wouldn’t be suitable for smaller organisations.

I’ve put together a (work-in-progress) note on segmenting software delivery organisations to show some different ways you can categorise an organisation with a view to making qualified rules of thumb along the lines of “If your org is in segment X, then do Y”. For example, if you’re a small autonomous dev team, then deploy your serverless app monolithically.

And finally, if you hear someone recommending a technology or approach that you’re considering using, ask them about the organisational context in which they successfully applied it. Their advice may not be relevant or even actively harmful for your situation.