Read the second half of it (It’s ~370 pages including appendices), and loved it!

In a nutshell, the idea behind Algebra-Driven Design is:

• Programming should not be code-centric; computer programs should be (only) the result of thinking about problems.
• So program source code itself is the wrong level of abstraction when thinking about solving most problems.
• Instead:
  1. Create a structured model of understanding. (An algebra, if you will).
  2. Check your model using e.g. QuickSpec to find out if your reasoning is correct, and what other laws might hold true to further refine it.
  3. The output of the previous step can be codified as a rigid set of properties which any implementation of your abstraction must adhere to to be correct.
  4. Only now we create an actual implementation based on the properties we’ve found. At every step of the way we can see whether we are on the right track because we have this clear suite of property-testing-properties available. This also means that refactoring and optimizing can be done fearlessly by anyone in the future.

Whenever we find a flaw in our reasoning, we can backtrack to an earlier step and continue from there.
And this is cheap since we haven’t committed hours or days to writing an implementation before finding out that the underlying concepts were incomplete or broken.

I think this workflow is beautiful. The one thing I am not entirely sold on yet, is on how widely it can be applied:
The book itself already states that this design flow is more ‘library-centric’ than ‘application-centric’,
although it also states that a concrete application ought to only be a thin wrapper around a group of reusable libraries (which I agree with).
However, while the two examples chosen in the book: ‘Functional Geometry’ and ‘Scavenger Hunt’ work really well for this technique,
there might be some survivorship bias here (these two examples might be chosen exactly because they work well).

I’ll have to try to apply Alg-DD to the ideas of me and my coworkers to see where its limits truly are.

In any case, I very much enjoyed the book, and whole-heartedly recommend it to people who want to learn a new technique for structuring their code.
The book explains the concepts it covers very well.
It should be easy to pick up for people who have a little functional programming skills.
It should also be possible to learn from it for people who do not have these skills yet (the book has a great appendix in which all the features the book uses are explained from the ground up), but it will definitely be a bit more challenging.

I do not think the techinques in the book are hard to learn; I do think that some of this knowledge goes ‘against the grain’ of current conventional Computing Science education,
which means that you might need some ‘un-learning’ if you’ve only encountered e.g. OOP with OOP-centric software design patterns so far.

Very much worth the price!

Going to be interesting hearing whether you thought it was worth the money

Some background in functional programming will help a lot (and it is probably the reason I was able to read through the book so quickly) but as bare prerequisite high-school math (i. e. working with equations involving variables and solving simple proofs with them) should be enough :-).