This is an older blog by me written in 2017, but this one remains pretty relevant. Hopefully it is also reasonably understandable (and interesting!) to any non-technical readers.

---

Art

I am always delighted when I meet a developer who calls programming art. I feel I have met a fellow soul. When I first learnt programming a few years ago, the fun of creation was quickly eclipsed by the delights of creating order and beauty out of chaos. One could not have imagined that organising the logic of indecipherable bits of text could be so fun (and I expect any non-programmer readers still cannot!). What was, however, most interesting was the observation that the same patterns one utilised in software to achieve this appeared in the real world. Complex systems naturally organised their constituent parts into grouping structures. The emergent property of this is the reduction of convoluted relationships that would otherwise propagate between components.

“Life imitates art” - Oscar Wilde

Oscar Wilde’s famous phrase seemed to me an excellent material to appropriate for the purpose of this post. Although - forgive me - I am more borrowing it for the basis of a catchy blog post title and instead wish to focus on its antithesis: mimesis. Whereas Wilde argued that art teaches us to see beauty in nature, and thus relegates beauty to be a perceived quality of nature, mimesis contends that and posits that nature is beauty.

The providence of the ideas of mimesis are Aristotle’s treatise Poetics. He defined art as the imitation of nature; it is the use of mathematical ideas and symmetry in the search for the perfect and the timeless. A parallel can be drawn with programming: it is also the seeking of harmony and beauty from the simplification of complex interactions. The structures displayed in software design, much like art, mimic the structures in nature.

Mircoservices

The concept of miscroservices provide an excellent illustration of this in action. They are the new buzzword these days. You are no cool developer unless you can say,

“I know microservices. We are the best of friends and go to all the parties together.”

Although what I have discovered is that parties with mircoservices generally involve a lot of people are super cliquey and no one will talk with just anyone. Lots of clustering of similar people. Why, you might ask, would you go to such a party. Well, what can I say, the group in charge of the music is excellent, and I always follow my ears. I do not know how they do it, but their behaviour can be trusted, the mechanism of which will become clear in the example below.

Chaos

Imagine ten people in a room with a very large cardboard box. You each give them a sheet of paper with a task written on it:

Assemble the ikea furniture in the box. Free meatballs once complete.

Some people’s faces would turn ashen grey from the thought of the indecipherable flat pack instructions. Others have their Pavlovian dog reflex activated.

In the box there are twenty chairs of two types, along with instructions, but only five keys. Some parts can be slotted together, others require the key.

All the people start grabbing parts and trying to put their stuff together. Bits of different chair get mixed up. People waste time waiting for a key to be free… someone gets bored and tries to build a ‘super chair’ using three chairs. They instead end up with a wonky table with five legs. All in all - chaos!

How can we turn the chaos into order?

We can organise the people as microservices. Firstly, one has to determine the key activities to be performed for the chair assembly. Then split the people into groups and let each group perform the allocated activity. Once they have finished their responsibility, they pass it to the next group. Much like at the microservice party with the music group, they are in charge of one defined behaviour to excel at, which has an expected result for the other groups to rely on. Interaction is reduced to the passing of completed items to the next group. Chaos no more.

The mathematics of this is pretty simple (at this level anyhow!). For those of you not familiar with Big-O notation, it is a means of describing how well an algorithm scales in computing science. Put very simply, in the context of this discussion, the larger the number one gets the less scalable (more complex) it is.

If we have a system where there is no division, the Big-O notation is O(n^2), which in plain English is termed ‘quadratic complexity’. This is where every component has the potential to interact with another, which can end up being a really rather large number. Imagine 100 people. Now square it. Big number. Instead, if we split it into 5 groups the Big-O notation is then O(n/5^2). 5 squared, as you are most certainly already aware, is a lot smaller than our original number.

Divide and conquer

This grouping happens time and time again in the world around us. For example, a company’s structure parallels a microservices architecture. Your call to your bank, is not to the bank, but to the customer services microservice. In Bango, for example, we have the (obviously very amazing) development team whose job it is to build our platform (and drink copious amounts of coffee). Their expected behaviour is to build the products requested, via the channels set up to request the work. They don’t suddenly start doing marketing, although that is possibly because it involves too much human interaction.

As an inherently intellectually limited human being, one cannot hold the multitude of different decisions that a piece of software makes. For a mind with such an ability, we will have to wait for Skynet and - most unfortunately - the enslavement of humanity.

Microservices contribute to the cessation of spending our lives wading through entangled spaghetti code - the structure of which resembles those cables you meant to untangle in 2003. By grouping, one minimizes the interactions between the different areas of a system, allowing for you the freedom to only have to comprehend your area of the system. This - for a lazy developer - is ideal. I for one, prefer to wade through something with a little more of the harmony and aesthetics that Aristotle would be delighted to include in a treatise on the imitation of the beauty of life.