01 April 2023
Most tables have four legs, each of which are positioned vertically on the corners of the table. After seeing only a few tables that appear that way, we can assume that that is the case for most, if not all, tables, including those we have not seen yet. We feel more confident in our assumption after understanding the underlying physical laws that influence tables’ design. And we are comforted by the fact that most tables we encounter do indeed fit with our model.
Software provides no such comfort.
Different software that behaves similary from the outside - for instance, a web API - might have implementations that vary along many axes: different languages, frameworks, libraries, tools, environments, architectures, coding conventions, and so forth. A developer wanting to dive into the code base for a particular program does not have assurance that what lies within is even remotely similar to a code base that he or she has dove into before, even on a program that has similar features. In addition, the same differences can also exist, in one way or another, even in the context of a code base for a single application.
This is bad news for writing adaptable software. To be able to quickly modify the code, we have to be able to grasp what it does. Grasping what code does is difficult in an unconstrained software environment, where there is a proliferation of different implementations, coding conventions, architectures, and so forth. And even when we understand how the existing code works, we would still have to think about which implementation to go with when we begin writing. All of this effort reduces the speed with which we can introduce changes and increases the chance of introducing unexpected behavior.
And so, developers have to be the ones to place the constraints. And constraints have indeed been placed, some stronger than others. One of the strongest constraints that have been placed are in the very languages we use to write software.
