Category: Books

I chose this book among others because I wanted to get out of reading about programming, methodologies, and other related stuff. I wanted to read something more abstract, not necessarily applicable to my immediate work, and boy did I get what I bargained for.

Well, let me start with complaints. First and foremost, the book is a bit long. I feel like it could have been compressed a bit. No, there isn’t much fluff, just several chapters could have been reorganized. Second, and no less subjective, the book at some point turns into a “horror movie,” where each passing chapter, things get more dangerous, complicated, and helpless. But I have to admit, there is a certain charm to such a delivery. Last grumble of mine: few examples of highly scaled and/or distributed systems. I would love to see more examples and discussions about them. Now I know the grumble isn’t entirely fair, since I got what I wanted – “more abstract” – but by the end of the book, I was left wanting more. I guess appetite comes during a meal.

Now let’s flip the page and go in the opposite direction: the examples in the book are quite interesting and educational. I loved the discussion about Twitter’s design and a couple more along the way. I personally don’t work with databases or other data-related systems that much, so the author fascinated me quite a bit. Some discussions are quite lengthy and detailed, mostly due to the complexity of the subject, but that’s what makes them so good, opening up your mind to different ways of thinking about programs, structures, and networks. The “horror movie” comes and goes, it makes you doubt everything you took for granted, even a CPU’s ability to add two numbers together. The author seems to project a lot of paranoia, the levels are similar to the amount of paranoia exhibited by system administrators. It sure gives a lot of perspective to developers, since lots of things are assumed to work properly and not to fail at the most opportune moment. One last thing: as I was reading the book, it reminded me of a bit of fun I had reading research papers at university. Some of the design patterns did emerge from academia, and perhaps it is a good direction if you have an interest in it.

I believe the title speaks for itself. If you want to design data-intensive applications, the book might be a good start. Perhaps it will give you a good insight and/or wider perspective. But if you are looking for hands-on material, the book might disappoint you. It is hard to tell whether the book is worth it or not. I had fun reading it; I believe it is well written, and I can see that the author put a lot of work into it. So I’ll leave you with this: if you are curious about the subject, go for it!

In a nutshell:
+: Well written
+: Broadens horizons
+: Lots of discussions and examples
+: No requirement for specialized knowledge
-/+: In a way, a long book; in a way, it needs to be longer
=: If you have any interest in application design, the book is an awesome way to start your journey.

Title: Designing Data-Intensive Applications
Author: Martin Kleppmann
Cover:

The material got into my hands from a friend of mine. Something tells me he never read the material, but somehow convinced me to read it. Let me say right off the bat, while the material is somewhat interesting and philosophical, rather than hands-on practical, I believe it is worth while.

From this point on, I’ll call it a book, even though it might not qualify. The book is a collection of brief and not terribly deep conversations on the topic of “getting rich”. Now, I can’t blame the author since Twitter is somewhat limited in terms of thought expression. Also the book leaves much to be desired in terms of structure and language. Quite often I had to do double, triple, quadruple take and still couldn’t understand a meaning behind a sentence. Yeah and I’m still calling it a book. But in this day and age perhaps none of this matters.

So will this book make me rich? Well, it’s up to you, or your genetics or upbringing or education and luck. But is there a “secret sauce”? Nope! Effectively the book just talks about your own behaviour and how to focus on essential things and let everything else go – because extreme focus on one thing, is exactly what it takes to get rich.

“Extreme people get extreme results.”

Sam Altman

So, no deep discussions, poorly written, no “secret sauce”, why should I bother? Because (in my opinion) the same techniques and ideas can be applied elsewhere. You don’t have to play status games, you should read books, you should learn to build, learn specific knowledge, you should experiment and go beyond recipe books. Not everything from the book will be applicable, but most of it seems like pretty universal advice that can be applied to other areas of life.

“Don’t partner with cynics and pessimists. Their beliefs are self-fulfilling.”

Naval Ravikant

I wish authors went deeper into discussions with more concrete examples and exercised more upon each topic. At times some material feels like pure philosophy – a wishful thought if I may. However I read few things before and able to fill some gaps or extrapolate some idea further, but I wonder how would this book read to someone without prior knowledge. Perhaps this is on purpose, by design – leave them striving for more and they shall achieve more.

“A calm mind, a fit body and a house full of love. These things can not be bought. They must be earned.”

Naval Ravikant

P.S: if you want to read the book, you can search online or download copy here

In a nutshell:
+: Short & fun read
+: Generally good advice / philosophy (not everything I agree with)
+: Get a feel for what it takes to be rich
-: Not a smooth read – text should be seriously cleaned up
-: Some topics are not well covered or expanded on
=: While the material is rough, some topics are not well covered and some ideas need deeper investigation, overall its worth the time. Philosophy feels quite universal, advices can be adopted for many situations and more importantly, continuous learning is something to be adopted.

Title: How to get rich (without getting lucky)
Author: Naval Ravikant, Babak Nivi
Cover:

I found out about Ricardo Semler from an IT blog, I don’t remember details, but the gist of it: successful Latin-American IT company follows Ricardo Semler’s approach – corporate democracy. The last bit peaked my curiosity, ultimately driving me to the book and let me say, if you never crossed the path, it is enlightening.

Every company wants to stay lean, competitive and ahead of the curve. There are multiple options to achieve it, however once a company grows, it inevitably gets fat and the ability to maneuver is diminished. Ricardo Semler addresses exactly the point – how to stay lean, agile, profitable in a competitive and turbulent environment.

“To survive in modern times, a company must have an organizational structure that accepts change as its basic premise, let’s tribal customs thrive, and fosters a power that is derived from respect, not rules. In other words, the successful companies will be the ones that put quality of life first. Do this and the rest – quality of product, productivity of workers, profits for all – will follow.“

The book is an easy read, the closest I can compare it to is “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win”. However Maverick is written from experience in a real company (Semco) and by a real CEO/Chairman (Ricardo Semler) – it is not a novel or a fantasy. The author has a nag for writing, I found the book entertaining to read, among other things. Described ideas, practices and methodologies that are innovative and provocative at least at a time the book was published – 1995. Not all ideas are original (but what’s new under the moon), some came from the land of rising sun, others from elsewhere, however all of them seem to be remixed and modified to fit the unique Brazilian market conditions Semco found itself in. Considering the age of the book, some of the ideas seemed to survive and flourish in fairly modern and big companies, such as Amazon and Netflix. As I was reading the book, I couldn’t help but say to myself: “oh look, Amazon does this…” or “sure sounds like Netflix’s approach”. I don’t know if those companies consciously adapted those ideas or arrived to the same ideas independently.

So it is fair to ask: is the book relevant after so many years? As I mentioned before, some modern companies already adopted some ideas, but not everything the author had to offer. There is more and the reason for more is fairly simple: the author is examining ideas, practices and methods that deal with human organizational conditions and not with any particular technical issue. Humans are slow to change and after decades of technological progress we still do business the good old way.

“The conflict between advanced technology and archaic mentality is, I believe, a major reason why the modern workplace is characterized by dissatisfaction, frustration, inflexibility, and stress. If only minds were as easy to change as machines. I’ll wager that it’s easier to invent a new generation of microchips than get a generation of middle managers to alter the routes they drive to work every day. Technology is transformed overnight; mentality takes generations to alter. Who can blame us for thinking technology will cure all that ails the workplace. It’s so much easier to acquire.”

In a nutshell:
+: Easy & fun read
+: Many great ideas, practices and methodologies
+: Based on real company and written by the CEO/Chairman
+: Great discussions and examples
+/-: Wound be great to have more details but not at the expense of abstract
=: I enjoyed the book. It contains lots of interesting, provocative and as years passed, very applicable ideas. I wish the author provided more details. Even if you have no interest in business, you might have lots of fun reading the book, at least I did.

Title: Maverick: The Success Story Behind the World’s Most Unusual Workplace
Author: Ricardo Semler
Cover:

I heard someone mentioning Eric Evans and DDD (Domain Driven Design) a few times and so I decided to see what’s its all about. It took me a while to get through the book, partly because I’m a slow reader, partly because the book is long and partly because the read is dry. As I was working through the book, I often wondered to myself: “is this still relevant?”.

Lots of described techniques are common place in everyday software development, however some of them evolved, for example: Microservice. It represents a bounded-context and due to the nature of a microservice, it is separated and doesn’t share objects or internals. Translators, entities, value objects and aggregates are fairly standard on projects I’ve been in so far. Layered architecture, frameworks, team work, supplier-consumer team relations, managers, refactoring and ivory tower architects are fascinating subjects, but again been there and done that. I’m not a history buff but I do enjoy it and so I find myself smiling reading through some parts, lets not forget the book is almost 20 years old. I did find an answer to one lurking question I had for a while: “why less capable engineers tend to accumulate in a legacy but still important, core software systems?” and let me say, Eric nailed it.

So some techniques might be dated but in my mind still relevant, however all of it is just peripheral stuff. What about the core? What about domain? Well this is where things get muddy for me. As I read through examples and discussions, I understood the value of good design, born in ubiquitous language, with help of business specialists, capable fearless engineers with commitment to deep thinking and forever deepening understanding of a business model. In theory DDD is the best thing that can ever happen on a project, however in reality (and by some degree of the author’s own admissions and disclaimers), DDD is not always the best choice or even a possibility. In my mind too many things must align in order for DDD to happen and bare fruit. In any system with many moving parts, there are things that can and typically will go wrong, especially when we are talking about creative work and human operated system.

But is the book still relevant? I think so, I would not be putting it on the top of “must read before programming”, but it still be on the list. I’m sure that commitment to deep thinking and modelling will not be going away any time soon. On top of it, perhaps as an industry we are no long bounded by monolith, but bounded-context is here to stay in one form or another.

In a nutshell:
-: long, dry read
-/+: relevance of some ideas in present software development
+: methodology to design and implementation
+: covers lots of aspects of system development
+: plenty of discussions
=: the book is good, I think people aspiring to be or current architects will reap lots of benefits. Few things feel dated but lots is still very much applicable and valuable. There are lots of books and materials that hold (IMHO) more value for developers in early and middle stages of learning the craft. But at some point Domain Driven Design should be considered.

Title: Domain-Driven Design: Tackling Complexity in the Heart of Software
Author: Eric Evans
Cover:

I took few notes during the read:

Robert C. Martin (aka uncle Bob) is one of the men who wrote Agile Manifesto. He created lots of worth while material for developers and championed TDD in a very hands-on approach – thanks for 3 laws of TDD.

I read couple of his books and watched countless hours of his teachings on YouTube. I invested heavily into TDD (thanks to Kent Beck ), which payed off for me in more ways than one and my commitment goes beyond words – please feel free to download and print TDD posters.

So I’m a fan, well… not really. I see lots of value in uncle Bob’s ideas and practices, so I have to give credit where it is due. However I don’t agree with everything he says and so I have couple of bones to pick over the book, but first things first.

The book came out at a very interesting times (end of 2019), when agile is a mainstream – everyone does agile now. Agile coaches without any technical background are training software teams, management happy to track development progress by every commit you make on hourly basis and damn the XP practices, full speed ahead. So timing of the book feels spot on, my only wish is that the book ends up in hands of managers.

But what about developers? Did I as a developer waste my time on the book? No, absolutely not! The book is a very good – easy read, short, concise and no fluff. It contains core concepts on what agile is, what it is meant for and all the practices associated. Now don’t expect details, it is a short book with it’s main focus on agile as a whole and not a full blown technical guide. However, it will provide enough to go and dig into each individual practice and believe me, some of these practices worth their own book. For example:

• Refactoring: Martin Fowler & Kent Beck – “Refactoring: Improving the Design of Existing Code”
• TDD: Kent Beck – “Test Driven Development: By Example”
• Branching: Paul Hammant & Steve Smith – “Trunk Based Development”
• Unit testing: Roy Osherove – “The Art of Unit Testing with examples in C#”
• Coding: Robert C. Martin – “Clean Code: A Handbook of Agile Software Craftsmanship”

Now I can’t shake the urge, so I’ll indulge it: I read Kent’s Beck TDD by example book in 2019, however the book originally was published in 2000 – speaking of being late to the party. By that time I was doing TDD for few years and participated in a few heated discussions on the subject. I guess 19 years is enough time for any subject to become semi-mysterious, bloated and extended beyond the original purpose. So the book was short of a revelation to me, it was simple, pure or how uncle Bob puts it: “back to basics”. It cleared the water, set boundaries and removed mysticism. Is it dated? Yes. Does it deal with modern complexity of micro services? No. But that’s the whole point: what is the original issue and how to deal with it; nothing more, nothing less.

Uncle’s Bob book is exactly the same way. It describes original issues and explains how to deal with them, nothing more and nothing less. If agile doesn’t fit into your team/organization then so be it. Don’t buy into over extended claims of agile industry that it will solve your problems. See for yourself what is agile all about, if it fits, go for it, if it doesn’t then look for something else. Perhaps there are next generation processes and perhaps they are based off agile, but don’t try to force something that doesn’t fit. One last note that I can’t pass, because it is personal and eats me up, I believe Kent Beck summarized it the best:

good engineering is only a small part of a successful project but bad engineering is main reason project fails

Kent Beck

Now it is time to pick a bone or two with the book. I respect uncle Bob and with this in mind let me ask: why go into something that he has limited knowledge and/or interest. In particular he offers his thoughts on agile in large enterprises. The subject came out iffy at best and confusing at worst. “Agile is for small teams” – yes and let’s leave it at that. There is no need to elaborate on the subject with dubious conclusion: world knows how to manage large projects, the modern society is a testament to that. I guess modern Boeing 737 MAX is also a testament to world’s ability to manage large projects. While he might be right, the book doesn’t answer or give much insight into the subject, so why talk about it at all?

Another bone is the value itself, I always been confused by the word and perhaps the whole argument stems from that, but let me elaborate. If we ask developer why he created so much code for let’s assume rather simple requirement, an answer could be: the code is fail safe, optimized and design wise allows for extensibility. Now in the mind of that developer he created ultimate value for the customer! What could be better than having a safe, fast and extendable code? Another developer might look at the same code with a very different perspective: it took too long to write, by making the code safe, it has many conditions that will never come to be, simply because such a data doesn’t happen that deep into the module. It is fast, but the functionality is not time bound, so unnecessary complexity for no apparent value. The code is extendable but no one has a crystal ball, so why make the code extendable at a cost to a customer who might not need to extend or modify it at all. Has this ever happened in your team?

Now I know, there are XP/Agile practices that guide us through all those tough technical challenges. But in order to invoke those practices (TDD, Simple design, refactoring, pair programming and so on) we must once again talk about the value. One developer with years of experience will look at TDD and say: “nonsense, overkill, waste of time”. Another developer might have exactly the opposite view, but do those opinions matter? If the entire team has to decide on values, then each opinion will matter, now it becomes a debate and political struggle to adopt XP practices/policies. More over how do you go about proving the value of those practices? The book says: “Instead of pushing TDD, maybe we could start agreeing on the value of reducing the time it takes to test our entire system. How long does it take today? Two hours? Two days? Two weeks? How many people are involved? What if we could reduce it to 20 minutes? Two minutes? Maybe even 2 seconds? And what if we could do that at any time just by pressing a button? Would that give us a good return on investment? Would that make our lives easier? Would we be able to release reliable software faster?”

Brilliant, we need to measure and record everything and apply statistics. Now, complexity of the decision making and cost of the entire team is going up, at the cost to a customer and thus far with no apparent value. And by the way, there are other ways to achieve the same result without let’s says TDD or any other practice. But let’s move on next and assume that we agreed on practices. Statistics is powerful, but does management need convincing? Do they want to spend more money? Is data all it takes to convince management and customers? Could there be other values at play? Ultimately a value is an elusive term, we all want a value but which one is a great question. Humanity is diverse and so value is very relative. All of us see value in different things even when statistics and data dictates otherwise. In lots of cases we don’t even have the right or enough data to deduce a value, yet we place bets and talk about the value.

Now the value topic is endless and perhaps I should examine it in a separate post, but now it’s time for final thoughts. The book has its flaws, some I discussed, some I didn’t (hello to end-to-end testing and QA responsibilities). However I wholeheartedly believe that the book is worthwhile the investment. Uncle Bob is entertaining as ever, the timing is spot on, the subject is fascinating and engaging. More importantly though, it brings agile back to the inception, drawing boundaries and highlighting essentials.

In a nutshell:
-: a bit short and has some confusing topics
+: easy read, to the point, concise
+: useful examples and discussions
+: helpful for managers, clients and developers
+: much needed refresh on agile
=: good book, has a lot of value for any developer, manager and client. Book is a bit short and some topics could have been expanded, but over all worthwhile the investment.

Title: Clean Agile: back to basics
Author: Robert C. Martin
Cover:

I made few note while I was reading the book, so I figured to leave them here just for fun: