Software engineering is the youngest and the most immature of all engineering disciplines. While all other branches of engineering have moved on full tilt into the incredibly productive world of simulation, software seems to remain sluggishly stuck in the early days of pioneering efforts.

There isn’t a modern development project, be it in civic engineering, pharmaceutical, automobile or aircraft, medical, pharmaceutical, financial etc. that is not 100% based on the discipline of virtualization. New cameras, newly designed smart phones, computers, any hardware, audacious enterprises to fly to Mars etc., understanding the patterns of pandemic, all those endeavors are progressing by simulating the conditions of the products or phenomena that do not exist yet.

It is only in software that we see raised eyebrows when we recommend that the solution be simulated before we actually build it. In that regard, software is indeed still stuck in the Stone Age.

Map and Territory

In the olden days when technology was very primitive, humans were interested in learning more about the concrete world that surrounds us. Many expeditions were sent to explore and measure the territories, and following such brave adventures, the collected measurements were abstracted into geographical maps.

Today, with technology getting incredibly advances, we are witnessing adventures going in the opposite direction: researchers and engineers are first embarking upon expeditions to invent maps, and only once maps have been drawn in many details would they embark upon building the territory implied by the maps. Which is to say, first we simulate something that does not exist yet, and only then do we materialize that simulation.

Software is perfect for simulation

In the days before we had software, we were crafting maps of non-existent territories by either shrinking large real-life objects to much smaller size, or enlarging small real-life objects to larger size.

For example, architects would construct miniature replicas of the buildings they were proposing to construct. Those miniature replicas were built using material at hand (cardboard, plastic, whathaveyou). And they were constructed BEFORE the actual construction on the site would commence.

Chemists would also construct replicas of molecules by using material at hand and then enlarging the real size of molecules (which are invisible to the naked eye).

Today, the simulation has been completely shifted to using software instead of real-life materials. Except, unfortunately, in the world of software engineering.

It is interesting how we often tend to refuse the opportunity to use software to simulate software products and services. But by doing so, we miss out on a great opportunity to speed up our delivery.

Software engineering processes such as TDD are an excellent remedy for this impasse. When doing TDD, we adopt the fake-it-till-you-make it approach. In other words, we start our work by first simulating some functionality that is not there. We begin from a broken system (a failed test). We simulate the breakage by fabricating incorrect values.

This breakage is a strong incentive for us to get the system back into the steady state (a healthy state). We do that by simulating desired functionality. We simulate by crafting interfaces.

Interfaces are a simulated stand-in for the real thing. By doing that, we are now actually crafting a map before there is any territory.

Based on such carefully crafted map, we now build the desired territory – that is to say, we implement the functionality that was simulated by the interface.

In doing that, we keep testing our system every step of the way. But our tests never touch the real thing – they only talk to the simulation (the virtualized thing, or the interface).