Software Projects and the Tower of Babel

The biblical myth of the Tower of Babel mourns what humanity had been capable of, had the Lord not chosen to confound our languages lest we learn to work together effectively.

I want to argue that even teams that share a common mother tongue get lost in translation more often than we might think and that this is an important contributor to project failure.

Why has humanity developed different languages in the first place? Arguably, we have very early been separated into tribes where communication inside the tribe matters more for survival than reaching out to individuals far away beyond our peer group. Language evolves according to need and groups that don’t communicate with each other regularly quite naturally see their languages diverge.

I would argue that the same thing happens inside your organization (insert a vague reference to Dunbar’s number here): You will certainly recognize that your finance department, your sales teams, and your engineers all adopt a very different jargon.

Often this is fine, especially as long as people are aware of the linguistic differences and can ask for a translation if needed. However, these differences become problematic when your teams employ the same word but understand it to mean different things.

There is a large number of terms that have been overloaded to a degree that, to me, the word itself has lost almost all usefulness.

Consider for example the expression “Big Data”. An analyst asking for a Big Data solution might have the following in mind: They face issues with their current rigid data warehousing solution and would like to start to indiscriminately collect unstructured data, figuring out the exact analytics later.

An Engineer asked to implement a Big Data solution will likely conclude that the requirement is a distributed system, a scalable cluster that can accommodate huge quantities of data.

These two concepts are correlated, of course, but there is no automatic link. Hiding the original problem behind an ambiguous expression closes a part of the solution space prematurely. Maybe even your “unstructured” data has an inherent structure that can be assumed? Maybe the volume is still small? Maybe consistency guarantees and interactivity are more important for your use case than scalability after all?

Similarly, two people may talk about “Agile” with one party referring to the ideals from the agile manifesto and the other party referring to a process like Scrum. They might talk about “Real-Time” with one party wanting an update on the same day that a change happens and the other party worrying about stop-the-world garbage collection pauses.

I think that we should all get into the habit of asking “what exactly do you mean when you say Big Data/Agile/Real-Time?”. The answer may very well be “I don’t know” which then is the starting point of an exploration of what problem you really want to solve and an important step to avoid building the wrong solution.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

Up ↑

%d bloggers like this: