| Software Development Pearls |
|
Author: Karl Wiegers But remember that a pearl is just a piece of grit that irritated an oyster. If you are not of the right mindset this book will also irritate but will the result be a pearl or just an irriatated reader? This book was suggested to me because I have professed admiration for the classic Programming Pearls by Jon Bentley, which is indeed a pearl of a book. If you haven't read that book you are missing out. Bentley's pearls are about programming practice. Admittedly dated now and almost in the punch card era but it is still a book of pearls. Karl Wieger's book isn't really of the same sort and it makes no mention of trying to live up to the reputation set by the predecessor whose name it has borrowed. It is a collection of "mottos" and observations rather than the invaluable nuggets based on coding experience that Jon Bentley provides. I have to say that despite searching for a pearl, I didn't find one and I suspect you have to lack the ability to think about what we do to find anything in this book informative, let alone a revelation. While the term "Software development" occurs in the title there isn't a line of code in the book that I can find, and you could republish it as a general guide to thinking and management with only a few changes of terminology and examples. Its almost a self help book with a spin of programming methodology and management. 
The book is structured into eight chapters that are only loosely on specific topics. Chapter 1 is a general intro to the book. Chapter 2 is a collection of 16 lessons on requirements - most of the recommendations I've read elsewhere and are fairly obvious if you think even a little about the problem. After reading a few of the lessons I began to anticipate the zen-like pronouncements that sound good, but are difficult to do anything practical with. For example: "Your goal is to develop requirements that are good enough to allow the next development stage to proceed" Easy to say, but difficult to achieve. Chapter 3 is a collection of five lessons on design. This is not the level of design I usually like to consider and again you will find a lot of vague generalizations that don't really give you the tools to apply anything. Mostly what is expressed is what is desirable and what are the goals, but not so much how to achieve them. Chapter 4 is about project management and takes the form of 11 lessons. This isn't project management as exemplified by a Gannt chart or a PERT diagram - more generalized wisdom that gives little idea how to apply it. Chapter 5 is takes the form of 8 lessons on culture and teamwork - what more can I say. Software development? Only tangentially and with some change in terminology it could apply to any management situation. Chapter 6 is about quality, which is a vague idea full of good intent. Chapter 7 is about process improvement which is an opportunity for vague "self improvement" mantras. Finally Chapter 8 is a short "What to do next". Conclusion You can tell I didn't like this book, but then I'm a developer not a manager. To call this a book of software development pearls is misleading. It's a book about how to manage software developers and it might appeal to a manager with such a team of cats to herd. Compared to other books of a similar sort it has little humour and little humility. More importantly, it has little that you can't find in other more technical accounts of the problem and it doesn't do as good a job in firing you up to do the job better. No pearls found here - well not by me at least...
To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for each day's new addition to Book Watch and for new reviews.
<ASIN:0201657880> |
|||
| Last Updated ( Tuesday, 19 September 2023 ) |