Verdict: Good
I’ve read Wiegers’ books on requirements (Software Requirements [1] – though I read an earlier edition – and More About Software Requirements [2], which seems to be out of print). I found them well written and practical so I was interested in reading Wiegers’ latest book.
The layout of the book is fairly standard, 8 chapters with each chapter containing several pithy one sentence ‘lessons’ that summarise the key points. The margins are somewhat over-decorated with icons that I don’t find much use.
Considering the author’s background, I was expecting a fair bit of this book to be on requirements. And indeed that is the case. There’s a fairly short introduction chapter and then the biggest chapter on requirements. This is good stuff, but if, like me, you already have the Software Requirements book, then this will somewhat reduce the value that you get from this book. The tone of the book is a bit business-y, with a lot of references to Business Analysts. There’s a bit of a gap between that and the engineering world that I live in. I like the idea of having well written requirements but at work, most of our projects are too small to need them.
The next two chapters, ‘Design’ and ‘Project Management’ (PM) are full of good advice and war stories from the author’s career. Personally, I find that these subjects are so situational that it is impossible to give any concrete advice that can be applied recipe-like.That said, Wiegers writes a lot of things that are sensible The emphasis is on doing design and getting it right. The main subjects for PM are estimation and planning. Wiegers uses pentagonal kiviat diagrams [3] to illustrate scope/quality/schedule/budget/staff. Looks good, but I’ve never seen anyone using them, The PM chapter finishes on the subject of risks and their mitigation.
Chapter 5 covers the human side of ‘Culture and Teamwork’. I think that this is an underdeveloped subject in software engineering books. Communication is very important but it’s tricky to balance with a productive work environment particularly for distributed teams.Wiegers also talks about the importance of knoledge sharing, training and scaling (growing teams).
Chapters 6 and 7 are close to my heart, ‘Quality’ and ‘Software Process Improvement’ (SPI). I agree with just about everything that Wiegers says.You can’t have too much quality (or to put that another way, I’ve never had enough quality). Wiegers warns us about silver-bullet tools and finishes chapter 7 with advice on keeping down technical debt. I have an unfortunately jaded view of SPI – I’m all for it as well, but most of my career has been spent in an environment where there are teams of developers and then a devops team. The devops folks provide the ‘process’ infrastructure but they don’t have any skin in the game of wring code daily. Unfortunately, a lot of managers seem to think that developers improving processes means they aren’t bashing out enough code. Chapter 7 ends with retrospectives – you’re not going to improve your processes if you don’t talk about what works (or not) and what might be improved.
The final chapter is about how to do all of these things. Don’t try everything at once, and try to have planning and a feedback cycle for the changes that you do make.
References
[1] Karl Wiegers and Joy Beatty (2013) Software Requirements, 3rd Edition, published by Microsoft Press, ISBN: 978-0735679665
[2] Karl Wiegers (2010) More About Software Requirements: Thorny Issues and Practical Advice, published by Microsoft Press, ISBN: 978-0735622678
[3] ‘Kiviat Diagraming’ on the Project Management.com website: https://www.projectmanagement.com/wikis/233065/kiviat-diagramming
