Most people are familiar with some variation of the idea that computers are all about “zeroes and ones”. This is true; in fact, the notion of binary code predates computers with a good margin, having been around since 1679.
However, if you drop by at the average developer meeting, in a company where digital products or services are made, you’d notice a striking lack of discussion about “zeroes and ones”.
The evolution of software development tools has happened at such pace that today creating entire application structures, hosting them in the cloud and delivering them to the world, can be done by a single person in the span of 15 minutes.
Despite the immense productivity gains in creating and managing the foundations upon which websites and services are built, there is still plenty of work left to do.
This work usually involves abstractions.
Abstractions in software development can be explained as the “meaningful objects” sourced from a business problem. As an example, if a business domain contains a “shopping cart” into which “products” can be “added”, you would likely find these same objects and actions represented in the source code as well.
Often the actual challenge, in any given project, is successfully modeling the given business problem into effective software, in other words: turning ideas into reality.
An example of abstraction levels in a project
Some of these challenges arise from the fact that business problems are usually at least partially unknown. For example, we might know that the products can indeed be added to the shopping cart. But do we always want to add just one product? What if the product comes in multiple colors, does it mean they are different products or the same product when counting the totals in the shopping cart?
Even very simple models and ideas can contain a lot of complexity when analyzed in a software development context. This complexity is rarely handled in plans or designs, as our brain allows us to adjust our abstractions and mental models very quickly. In the software abstractions and models, rapid change is thought to be best dealt with through agile methods and practices.
But as quick as turning things around in a single development sprint is, shaping the correct abstractions should start well before the first lines of codes are written.
So how do we create good abstractions? Our abstractions should:
1) Only contain detail that matters. This is tricky because both too high or low level of detail can get us into trouble when implementing the abstraction or when reacting to changes in the business problem. Our selected level of detail should enable all the stakeholders to discuss the matter, but also survive the real world as a piece of working code.
2) Be composable. This means that the objects and models we create should fit together nicely. In our example our shopping cart can have products “in it”, and if we introduced an action like “checkout”, then it could be defined as some process being applied to the shopping cart contents.
3) Be simple to understand. Even if dealing with a complicated subject matter, there are some common signs that something is not quite right. For example, if a lot of conditional rules start to appear, such as having “business products” for “business customers” and “consumer products” for “consumer customers”, but also “products for all customers”, it might be a good time to check that our abstractions are indeed representing the business problem correctly.
So stick your head into that developer meeting. Chances are, they’re working on things, rather than just bits.
