Review? The Essence of Software

Book with quite a grand claim to spot the “Essence of Software”, but after reading it - I’d recommend it for people working on creating software/product systems, I’d recommend it a lot.

It doesn’t seem very popular (Goodreads), but it’s one of the recent ones that gave some answers to a few headscratchers I might’ve seen recently in day-to-day work and the past.

As for the context from the author:

• He’s the person who developed a language for the formal modeling of software, you might rightly presume some light deepdive into that.
• He’s been writing that book for a long time (mentions first draft in 2013), hence even as it’s published in 2021, the examples are leaning towards the software 1.5/2 era.

So, with the above, my impression is highly positive, although one could argue that it’s a bit too long, as the basis for ideas is highlighted pretty early and pretty nicely.

What’s it about? One could say that it’s about the technological strategy from the perspective of developer/architect-craftsman. Meaning one who really admires the beauty of consistent software behavior - imagine learning about inventing the ‘Trash’ folder in the OS, it’s quite brilliant. At the same time:

• It’s an unobvious software problem - you create an ability to ‘un-delete’ files throughout the OS.
• You’re doing it in a completely novel interface setup - as before that, ‘user-friendly’ GUIs didn’t exist.

If you still don’t see the point - it’s about the one where it’d be fine to describe for what felt like a good quarter of the book, references on all different issues in weird synchronisation states - across backup systems, Drive/Dropbox, etc.

And as it just feels like there are lots of things flying around, it shows some beautiful concept-based software building theory.

Which, in essence, says that things should do what you expect them to do. And it’s not trivial that - I’ve mentioned that sometimes you don’t see said issue with the product/idea/service and usually people ask ‘what does it do?’.

And frequently explanation goes straight - ‘It does X’, so the main difference from the book, it’d show the answer to that from a software standpoint: “you need to have a ‘Concept’ that does ‘X’ and has a certain list of properties”. Think of Facebook’ - Post, Like, Friend, etc.

It explains clearly that concepts should have purpose, shows that relationships between them matter and actions/methods, etc. which are consistent or not, i.e.

• Concept should have only 1 purpose
• Redundancy - 2 concepts for same purpose
• Overload - 2 purposes for one concept
• etc.

When one processes it, they might want to subscribe to the preaching and see the software world just a little bit differently.

It shows that clear concept understanding of the product is half the battle, and even mentions ‘killer-concept’ as a token instead of the usual ‘killer-feature’, clearly meaning that product differentiation goes not through exact implementation, but to the aim of purposes being addressed properly, consistently, maybe (?) in a novel and unobvious fashion.

As a shy example - “Friend”/”Follower” concept creation did enable a Growth Loop for certain set of products.

What even more straightforward - sometimes it can be a nudge against ‘bad’ MVPs, meaning:

"The unfinished concept sometimes might be the reason for failed hypothesis."

• See the example of having ‘friend’ concept in social network, ‘friend’ button, but no way to see own list of friends?
• Or one puts/creates a ‘product’/‘order’/’query’/etc. but sees no obvious way to cancel/edit/delete something.

The above is probably a not-unique example of reasons, but I find it quite usable - what would constitute an MVP not from a ‘feature-set’ perspective, but from a software concept/model, and it should just show a mental red flag when the essential purpose of some part is forgotten.

And a bit different example - one that I’d just speculate about. In many grown operations one would be working with design systems and in interpretation I understand, it’s a very productive entity that allows shipping consistent experience. You’d usually have a certain standardisation over UI elements.

So, the software concept is not that all, but partially related still - it shows that you can’t invent a ‘Post’ having some default elements, and you can’t use those elements to make sure your experience of working with that concept is logically consistent. You’d need a foundation for that to be built.

As another fresh example, I recently saw the designers sharing WWDC part on Carplay, where the Design System for car developers/manufacturers was presented

From the picture, you can right away gather that it’s a design system - it has layouts, elements, gradients, etc.

But following the interpretation of the book, I want to mention that the more interesting part under the iceberg tip of design is a set of concepts that ‘the Design System serves to power’. It’s needed to show a ‘Speedometer’ which would technically get a set of data points at all times (think fuel, mileage, speed, etc.) and should not only be ‘surfaced’ in a certain way but actually ‘behave’ in a certain way.

So the success of the above product for CarPlay could be closer related not to design, but to integrations/logical foundation, it’d allow for developers to leverage the work with those elements.

I.e. imagine a digital speedometer concept that would only be able to gather and show only one data point at a time due to some technical limitation, could that be a pleasant product even though beautiful?

Anyway, if you sometimes feel that the product you use or build works a little bit wrong, maybe you could check out the book, and the author’s blog and find that the reason might hide in a conceptual world.