Review of “Nature of Software Development”
This book by Ron Jeffries is a quick, easy, and interesting read. So, if you are looking for some light reading about software development this holiday season (say, while on the road), pick this up.
Now to the question “why is it interesting?” Unlike books on software engineering, it is not a book about processes to build software. It is definitely not about programming. It is not about best practices.
Instead, the book advocates a principle to build software. While the principle in hindsight will seem obvious, we often fail to stick with it. The principle is always being value-driven.
The value delivered to the users by the software (when delivered on time) should guide the development of software.
Beyond merely laying down the importance of being value-driven, the book provides convincing argument about how to be value-driven by leveraging existing methods and practices, e.g., refactoring, user stories, (A)TDD, Scrum, Agile methods. While the book prescribes more autonomy and power to development teams, it also describes the role of management in such as setting. In addition, the book introduces the term feature-by-feature development, which is exactly what it means and seems obvious when executed.
I strongly recommend this book if you are interested in software development or just building things.
To whet your appetite, here are some of the highlights in my copy of book :)
- A focus on delivering value early and often.
- The main thing to remember is that we get the best results from delivering the software, feature by feature.
- Organize by feature.
- We need to defer implementing low-value ideas indefinitely.
- Set a time and money budget; produce the most valuable features first; keep the product ready to ship at any time — and stop when the clock runs out.
- Organize into small teams, each of which builds features that the product champions (end users) can understand.
- It’s better to break down stories into smaller stories (features), each making sense to the business-side people.
- The point isn’t to make good estimates — the point is to do good work at a consistent pace.
- As soon as you realize the team has taken on too much, remove something from their plate.
- Eliminate defects to provide clarity on what’s done.
- The best known way to keep up is to express our features in terms of the tests they must pass, and to automate the tests to give us assurance that the feature works now, and from now on.
- We need a high-quality design at every moment.
- Testing and refactoring work together to make feature-by-feature development possible.
- Managing by looking at value works better than managing by dates or artifacts that don’t deliver value.
- The main idea is to concentrate on value, not cost, and to see the value in terms of real, running software with features we can understand.
- Look at two things your numbers suggest and ask yourself whether you agree. If you do, go ahead. If not, that’s interesting! Dig into that until you and your numbers agree. If they just won’t, I’d advise throwing out the numbers. [This one struck a chord with my data science-y self.]
- Every aspect of this work is complex, but we do not need a complex process to do the work.
- Product champion shows what problem to solve; the team decides how to solve it.
- Allow the people closer to the work to make most of the decisions about what to do and how to organize to do it.
- Increase individual productivity by increasing capability, not by urging people to work harder.
- The fastest teams move smoothly and gracefully.
- A highly paid expert shouldn’t be highly paid just because she’s an expert. She should be highly paid because she is helping other people become experts.
