Context is King

We humans have this remarkable ability of using context to understand and act upon situations. We are able to understand the different meaning of the exact same thing said based on the context. We take appropriately different actions for situations that are apparently very similar. And yet we find in many areas of life and work that the acknowledgement and use of context takes a back seat. For example in the world of software development.

The software world has an abundance of contributions from practitioners, experts and researchers in the forms of best practices, industry standards, frameworks, methodologies, patterns and libraries. These provide a lot of benefit to the extended community. For example to avoid reinventing the wheel, to save time, to avoid common pitfalls, to achieve certain levels of quality assurance levels, to achieve better efficiency, security, reusability, maintainability, and other software quality metrics. Just like any other human creation, each of these can be put to best use and benefit if they are chosen (or not) wisely. 

For example, if you choose a sharp pencil to hammer a hole in the wall, you’d get disappointing results despite the ingenuity of the creation of sharp pencil. If you try to write on a piece of paper with a nail, you’d be disappointed too, despite the usefulness of a nail. If you try to force and use a nail or a sharp pencil in its original form to do something that cannot be satisfactorily achieved with either of them, you are being naive at best. It is the context that can always correctly guide you whether any of the existing tools is a good choice for what you are trying to do, or whether you need to modify one of them or a combination of them, or create one yourself to serve the purpose of your context.

In the software world if we don’t have our eyes on our goals, and if we don’t give context its due importance, it is very easy to slide in the lure of using any of the amazing contributions by other people, whether it serves the purpose in the best way or not. I’ve alluded to the importance of context in software design in my article here: https://www.dhirubhai.net/pulse/impact-software-design-considerations-ali-rizvi/. If you hear someone insisting on using a best practice or framework or pattern just because it is the recommended or popular or best practice, then that is a red flag. There should be adequate contextual reasons to justify the use of a framework or pattern. The absence of any such contextual reasons is an indicator that the goal of what you are trying to create is not being best served.

Next time when you find yourself making choice of a technology or framework or pattern or methodology, do audit your reasons. Are your reasons relevant to your context? It will help you make better choices, make your project journey easier, and your goal will have a better chance of being achieved comprehensively.