The Nature of Software Development

Time has come for me to do a another book review. Now it’s ”The Nature of Software Development” by Ron Jeffries (one of the original Agile Manifesto signatories, @RonJeffries on Twitter). It was published 2015 and is a truly agile book with 150 pages full of wisdom! And questions. That can raise wisdom. If you ask me, I think this book is fantastic! Let me try to explain why, whilst sharing some quotes from the book.



A few weeks ago I attended Lean Kanban Nordic 2015 in Stockholm. Henrik Kniberg did a keynote presentation with the title ”The Art of Figuring Out What to Build”. It was all about focusing on building the right things, the ones that brings value to the customer. This shall be done in smaller increments to allow fast feedback to avoid the ”big bang”-approach that is the case with the Waterfall-method. As you will see, this resonates 100% with what is written in this book.

”Here’s a better way: set a time and money budget, produce the most valuable features first; keep the product ready to ship at all time – and stop when the clock runs out.” – Ron Jeffries


The book consist of 22 short chapters and they are divided into two parts:

  • Part I – The Circle of Value
  • Part II – Notes and Essays

The first part starts by stating ”As we do, your job is to think a lot, while I write very little”. A lot of thoughtful questions are raised throughout the book, time should be spent thinking of those! First out in the book is value, that is the point of our work, and stated to be ”what you want”. We should ship value in smaller pieces.

How should we bring value? One key component is to organize ourselves into small teams that deliver features, feature teams. Persons that share the same competence in the feature teams will form a guild or community of practice. Things go best with frequent releases of the software. We should not think or keep track of low-value ideas. Two levels are used to describe functionality; features -> stories. Stories is not recommended to be broken down into tasks, but rather smaller stories. As for planning use ”Yesterday’s Weather”. You will probably get as much done in this coming iteration, as you did in the last one. If you need to state how long things will take, just count the things that are done and make a prediction.

Build your product, feature by feature. For this to work the product needs to be nearly free of defects after each iteration (two week period). In fact, the product needs to be nearly free of defects all the time! The features needs to be build upon a solid foundation or ”infrastructure”, that is developed at the same time as the features. We test at two levels, with ”Business” tests and ”Programmer” tests. All these tests needs to be automated. Refactoring is also essential.

Ron Jeffries emphasize ”Show us the software”, for him meaning:

  • Focus on value for best result
  • Produce real software often
  • Build in small steps for faster feedback
  • Learn the planning and management skills needed

Management shall state what to do, but leave to the teams the how to do it. Management shall also limit the number of products and programs to work on, since working on a lot of things in parallel just slows everything down.

In chapter 20, the final point is ”Most of all, think”. Building a product is complex, you should use inspect and adapt.

”Dirty code slows you down as well. If the code is clean, the next features go in smoothly.” – Ron Jeffries


This is a true master piece! Since the chapters are so short and to the point, it’s almost like reading poetry. Agile poetry. This is the ”true north” or ”guiding star” in Agile we all should aim for! In 5 to 10 years from now, everything in this book will seem darn obvious and the whole software industry will be working this way. Hopefully. If everybody reads it. I check on Amazon and see that the book is only in place #222,501. That worries me. A lot. So read it and spread the word, like me and others have done.

”Generally speaking, estimates are likely to be wrong, and they focus our attention on the cost of things rather than on value. Consider de-emphasizing or eliminating cost estimates and steering to success by a focus on value.” – Ron Jeffries

All the best,
 Tomas from TheAgileist

One comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s