Recommended with reservations (depends on the audience)

I’ve been a software engineer for some time now, and there have been quite a few books on the various disciplines involved in Software Development. And many of them are weighty tomes, that go in to great depth in to each topic, which is brilliant for those who like to know every tiny thing; however, this book is a much smaller volume, and can easily be read over a few days.

The book is split in to several chapters, and each chapter covers a specific section of software development. These sections are requirements, design, project management, culture and team work, quality and process improvement. And each chapter is broken down in to a series of lessons, it’s similar in format to the 97 things… series that O’Reilly publish.

Chapter 2 focusses on requirements, and is probably the longest, and it’s one I must confess I spent the longest time reading, as it’s always something I’ve personally struggled with. And I found the tone familiar and reassuring. He makes the case for clear language and vocabulary when eliciting requirements. He also challenges certain pre-conceptions as well, such as the use of ‘gathering’ requirements, as though they’re something to be found.

He also goes in to other techniques of eliciting requirements rather than just been sat in a room full of people, I particularly found the case for prototyping compelling, Wiegers argues that it’s better to have something in front of the users that they can play with, which will elicit questions, as well as encourage better dialogue and less time spent shoe-horning things at a later time.

Chapter 3 is a collection of lessons on design. And while it works on a higher level setting nice goals, it doesn’t really give you a framework of how to get there. I suppose there are a wealth of books on software design that would fulfil this need.

Chapter 4 is about project management. It’s worth noting it’s not Gannt charts or PRINCE related guidance, but more of a general guide on how to do project management. I’m afraid this part didn’t interest me at all, which may say more about me than the author.

There’s a chapter about culture and team work, and as more and more companies now look for a cultural fit when hiring, this seems like quite an apt chapter. One could argue ‘what has this got to do with software development?’ Well software is developed in teams, and you need a good culture within that team if stuff is going to be delivered on spec and on time. But I think other books cover this material better, especially for programmers in particular.

If you’re expecting something similar to Jon Bentley’s Programming Pearls, then you’re not going to be happy. I’d say that this book isn’t for code-cutting programmers. I’d argue it’s aimed more at those with a people-facing role, tailored more towards team managers, business analysts and such. It’s a book more geared towards running a software team, rather than actually developing software. So if you’re a manager, you’ll get some mileage out of this, if you’re a programmer, probably not as much.

Website: https://www.oreilly.com/library/view/software-development-pearls/9780137487806/