In this blog post I talk about the book The Nature of Software Development, written by Ron Jeffries and published in February of this year. To quote Wikipedia, Ron Jeffries is one of the 3 founders of the Extreme Programming (XP) software development methodology in 1996. My introduction to XP was about 4 years later. His website XProgramming.com was one of the first websites I mined for information about XP. He literally has a lifetime of software development experience and whenever he writes, blogs or tweets, I take note.
What the book is about
Every software developer knows that building a product can be a painful experience. I am not so much talking about the technical aspects but more the questions of what to build and when. There are a lot of things that can make a seemingly simple job difficult, e.g. requirements that are unclear or change, deadlines that turn out to be unreachable. Mr. Jeffries wants to show us that there is safe way through the field of lava that a software development project might resemble.
In the Introduction of his book, Mr. Jeffries states the following:
Come along with me, and explore how we can make software development simpler by focusing on frequent delivery of visible value.
The gist of the book is a familiar one, namely that we should deliver value to the customer feature by feature. The following quotes are from the Chapter 2, "Value Is What We want"
We need to build pieces that make sense to us, and to our users. These are often called minimal marketable features (MMFs).
we [...] benefit from providing business features at an even finer grain than the usual MMF.
The book discusses these notions and their impact on other aspects of software development, such as planning, design and quality.
A lot, if not most of the things in the book you will have heard before. But the value of The Nature of Software Development is in the way it presents their combination to the reader. When you read the book, it feels like Mr. Jeffries is sitting next to you, as if you are having a conversation. If you are open to the approach (to software development) he advocates, the book will invigorate you to tackle that difficult software project at work.
However, if you are skeptical about his approach, I can imagine that Mr. Jeffries alone will not convince you. That it sounds so deceptively simple does not help. He kind-of addresses that simplicity in Chapter 13, "Not that simple". There he acknowledges that "real business" will complicate things, but that "it's all about deciding what we want, guiding ourselves toward what we really want". True, but the "we" can be a large "we": stakeholders such as developers, architects, project managers and customers have to be on board also. You will have to overcome any skepticism by any of these parties, so prepare to encounter the "that will never work for our situation".
I have seen software that was late due to features that were "really necessary for the first release" but which needed a lot of rework afterwards. I have also seen software that was late end up in a drawer because apart from being late, it was also unusable. To avoid that I prefer to build an application feature by feature, slice by slice. The Nature of Software Development confirms my personal experience and beliefs with a clarity and completeness my own thoughts on this subject lack. I can thoroughly recommend it.