Author: David Farley
Pages: 256
ISBN: 978-0137314911
Print:0137314914
Kindle: B09GG6XKS4
Audience: Software Engineers
Rating: 3.5
Reviewer: Kay Ewbank

This book is subtitled 'doing what works to build better software faster' - does it teach you how to achieve that?

The advice given in the book certainly makes a lot of sense, and in general follows mainstream software development concepts. We're talking broad brush theory here, though.

 

David Farley writes well, and has a popular YouTube channel that covers a similar range of topics to those found in the book. He opens with the question 'what is software engineering?', and looks at the wider question of what engineering in general is and how to apply this to coding.

Next the book considers how to optimize for learning, with chapters on working iteratively, the importance of feedback, working incrementally, empiricism, and being experimental. The chapter on empiricism looks at how hypotheses need to be tested against observations, while the chapter on being experimental considers how to perform procedures to support, refute or validate a hypothesis. If you think those ideas are very similar, that is one of the problems of the book - there's a lot that is quite repetitive.

The next part of the book is about optimizing for managing complexity, with chapters on modularity, cohesion, separating multiple concerns, information hiding and abstraction, and managing coupling. This last chapter looks at how to avoid interdependence between software modules. Farley puts forward microservices as a possible way around coupling, points out that decoupling often increases the amount of code, and looks at various techniques for loose coupling.

The final part of the book looks at tools to support engineering in software, with sections on testing, measuring, and continuous delivery.

I found it difficult to work out what my conclusions were about this book. The theories discussed are relatively well known and accepted. Most of the chapters I read while nodding my head in agreement. Farley writes well and his examples and analogies are good. Given the restrictions of space and the massiveness of the topic, it's perhaps understandable that he sticks to broad brushstrokes, and doesn't (for me) do enough of 'so what you need to do is xxx', or 'here's how to achieve this when you are working to a fixed budget and timescale for an unreasonable client'. Nobody is going to do wrong by reading the book, the advice and observations are all useful, but don't expect any magic bullets.

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.