Conventions and Unconvention

There have been a series of arguments, especially in the African tech scene, around “enterprise” software engineering languages.

Granted, we all agree that it usually lacks merit. But for argument sake, lets look beyond the initial “craze”.

First we start with how large scale products are engineered, we contrast this with cooking.

Lets say you want to cook a pot of egusi (your software product), you have a team of 6 chefs (your dev team). Now each chef has their own way of cooking egusi, some use bitterleaf, some use another leaf, some prefer it with chicken, some beef, some prefer palm oil, some groundnut oil etc.

As a head chef (Engineering manager) in charge of building this pot of soup. How do you ensure you get the best out of all these chefs with their different expertise and process, but center that towards one goal?

You start by creating a single way for them to cook, a set of rules on how this pot of soup should be cooked. These rules are called Conventions.

They can be: what type of leaf to use? what type of protein to use? how long should these ingredients boil for? What oil to use, maggi, thyme? etc

In the software engineering world, we call these rules “software engineering conventions”. They revolve around variable naming, folder structure, software design principles etc.

Why do we need them? In the case of our egusi soup, there is a saying “too many chef spoil the broth”. This doesn’t take into account the use of cooking conventions

A quick google search would show a host of meals which have been prepared by a large number of people. It is the same with software products

In the world of Open Source Software contributions, this is Infact key. You have millions of people contributing to a particular project, without key conventions around that project, everything falls into disarray

Please forgive my cooking skills, or lack of it. No cooking ingredient was harmed (or house burned) in the composing of this article