The last technical book that I’ve recently read is The Nature of Software Development by Ron Jeffries. Manu Rivero recommended it to me inasmuch as he’d read it recently, and as I trust his criteria, I decided to read it. I want to divide this “review” into three sections: my reading experience (as a journal, to return to just in case I re-read it), what I got from it (given my current context and knowledge) and what knowledge I think someone else might get.

My sensations

I think that it’s fair to say the book is well written. It was smooth reading and it was never stodgy. Every concept is well split up and each section delivers a little piece of knowledge that is easily understandable. In Spanish, we have a saying that defines this book so well: “cortita y al pie”.

It’s also accompanied by some drawings that help the author to explain each idea. They are not perfect but are simple and mostly, effective.

However, I feel that it didn’t bring me new disruptive concepts. The vast majority of ideas that I found remind me of the core ideas of agile software development. Well explained and effectively presented, but not much more. However, I think that it’s a book that should be read by any tech lead or CTO, if you keep reading I hope you understand why.

What I got from it

Okay, maybe it hasn’t brought me any new ideas but was it a waste of time? Absolutely not. I strongly agree with Eugène Ionesco’s quote: “It is not the answer that enlightens, but the question” and I think this book wheels out excellent questions at the end of each section. Even if you know all the concepts from the book, if you make the effort, I believe you will find new perspectives on your day-to-day problems. So, the first is a good pool of questions to always return to at some point.

The second valuable thing that I got is an excellent way to deliver these ideas. I knew them, but this is not the same as having the skill to bring them to a discussion or chain them in a presentation with your lead. Each idea is held by a solid metaphor and at the same time supported by other ideas. Maybe I’m not going to use them in the same way but it has given me new approaches or pictures about the nature of software development, which adds more resources to my pool.

The most concrete valuable thing that I’ve taken away is the reflection on what value actually is. At the time of reading the book, I was on a discovery team, where our mission was to innovate and work on disruptive solutions for our users. And often the discussions were around what innovation is (which deserves a full post) and what is the most valuable thing that we can do?. And even though it is a concrete and clear question its answer is not because value depends on the context and many other factors. What is value in my context? or, what value am I trying to get? are two questions that have frequently come to mind lately. Although I rarely find a good answer, I believe that thinking about that keeps me away from being (too) wrong.

What you could get from it

Okay, this was my experience but what happens if you are starting to read about agile, how to improve your development approaches or how to deliver value fast? Could this book give something to you? Absolutely yes.

If you are used to delivering value on huge blocks, have a QA and bug fixing phase after each development cycle or even worse betting on all or nothing releasing, this book will bring you a new perspective about how things can be done. Jeffries explains very well the importance of building the software incrementally and why it should be done in this way.

Related to that, the author also talks about the prioritization-estimation duo. He provides solid reasonings about how you should prioritize given the uncertainty, value and effort and why you should spending too much energy on estimation due to the volatility and the changeability of the context.

If you have ever experienced a downshifting speed when developing a new product or great difficulty iterating the product and you don’t understand why this book can offer you new perspectives. It’s not a technical book about how to manage technical debt or how to develop code to make it easier to change. It only brings a few ideas about what you should care about when developing software focusing on quality and sustainability. If you have never been exposed to them you can make a valuable discovery.

And the last thing is a different way to manage teams. If you are used to seeing traditional management (order and command) you will find a totally different approach based on trust, autonomy and delegation.



Hope you’ve found something useful, and if you’ve read the book and have a different opinion, don’t hesitate to share your thoughts. I will be happy to know about it 😄.

PS: Thanks again to Anna and Em to helped me with the English