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 in 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 basically 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.

Essentially, 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 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.