Automated Defect Prevention: Best Practices in Software Management [Hardcover]

I've read this book from cover to cover. I've read many books on software development, software processes, best practices, qualitative approaches, and quantitative approaches, many from SEI. This book has to be one of the top two. For software professionals in leadership positions facing today's pressures of delivering quality software that meets customer expectations according to plan, this book is a must-read. You will be able to implement techniques directly into your organizational processes and deliverables with considerable ease. Kolawa and Huizinga have forged a grimoire that should be on every software leaders' desk, be they Project Managers, Software Architects, PMO Directors, of Vice Presidents of Development. Here are the key take-aways from this book:

1. Clarity: All concepts, practices, and examples were extraordinarily clear. There was never a question as to what was meant, or confusion in the information conveyed.

2. Readability: The text is very user-friendly. Coming from a very technical background, I tend to read challenging and complicated material. In this book, you were able to frame both technical and complex material in a readable way. In other words, I never had to re-read anything in the book. All of the material was very easy to understand. I feel the ability to effectively reduce complexity to simplicity is the hallmark of good authorship.

3. Implementable: I found the practice-side of the book to be what I call `out-of-the-box.' This means I was able to take material directly from the text and apply that into my process(es) or deliverables with very little work or trouble. (I actually did this multiple times.) This is a testament to the subtitle of the book, Best Practices in Software Management.

4. Usefulness: The book is actually aimed at being useful within for-profit businesses. Theoretical books are good for concepts, but it's up to the readers to find ways to translate the theory into executable practices (which often is beyond the role and responsibility of the readers). Your book actually bridges this gap, and provides mechanisms to help readers implement valuable techniques into their organizations, independent of their infrastructure.

These four points make a huge difference for readers looking to improve their software development processes to ensure profitability, cost savings, and customer satisfaction. Producing quality software while building defect prevention into your processes is key in today's competitive software marketplace. With these techniques, your organization will continue to become better, managing, reducing, and even eliminating the traditional sources of defects in software deliverables. You won't be disappointed in buying this book, as you'll refer to over and over again as you build process improvement into your organization.

One issue I have with the software industry is that too many project managers, or stake holders managing software people, lack the understanding of just how important software quality is and how it can benefit the software teams and products. As the people most accountable for what happens with a software initiative, managers should have a solid understanding of what options are available to improve developer skills and the software they release. This book provides that needed information and helps explain who is responsible for what tasks, when they should be considering phasing in a particular practice and the benefits of a given item.

I like the way the information is presented in this book because I feel a project manager would be able to quickly evaluate a practice for phasing in without facing an all-or-nothing approach that some other books take. If, for example, a manager felt that they enjoyed the chapter on testing models, this book provides the information on what is needed, the benefits and the roles people need to take to phase that approach into their teams.

I enjoyed this book and I wish that more development teams used many of the practices in this book. While there were samples at the end of the chapters and a chapter on case studies, I would have liked to have seen a bit more information on difficulty and time constraints presented within some of the sections themselves. Overall this is a great book and definitely worth having on your desk.

Software engineers encounter tooling for planning, assessment and document management. These systems enable teams to know baseline work products as they evolve. Effective tooling is also appropriate for software developers. What would Henry Ford have achieved if he focused his automation effort only on administrative and clerical activities while ignoring the production line? Automating core software product development presents both challenge and opportunity.
This book provides a practical, systematic and comprehensive Automated Defect Prevention (ADP) based software development process model. ADP builds upon people and technology infrastructure, automation and best practices. As they collaborate, people are assigned certain roles, and various technologies have certain roles. When learning better ways to efficiently produce high quality software related work products, the larger team can also benefit, but only if knowledge gained is effectively shared and used. Experience must be captured in a repository. People must be properly motivated to contribute to and reference a repository. Automation of best practices enables beneficial application and retention of lessons learned.
The book observes that a large measure of overall software engineering effort presently goes towards finding and fixing defects. By contrast, defect prevention, reducing the number of initially occurring defects to be found later, represents genuine opportunity to improve efficiency. Understanding the underlying root cause of a class of defects enables development of preventive action plans, and process improvements to prevent recurrence. Automation of preventive action improves process compliance, predictability and product quality. It is duly noted that automation can itself be a significant challenge. However, improvements contribute to customer satisfaction as well as to job satisfaction and productivity. Successfully automating portions of what our software engineers are presently doing relieves tedium and allows for more creative engineering focus. We also gain opportunities to automate reliable measurement of process performance.
The authors recognize process change challenges, and provide an incremental evolutionary approach to phasing in ADP. They apply ADP to, "initial planning and requirements, expanded planning and design, construction and testing, and deployment." Best practices coverage for each software development phase includes characterization of the problem addressed, identification of team members performing the practice, description of practice implementation, and automation. Measurement and tracking also benefit from automation. These measurements support more effective management decision making, systematically providing value above and beyond the basic contribution of each individual.
Important words of caution are provided. There are no silver bullets. Some human activities do not lend themselves to automation. Examples include requirements elicitation, architectural design, documentation peer review and various activities related to creativity and innovation. The authors emphasize appropriate use of measurement and tracking data, and perhaps more importantly the absolute necessity for management to prohibit inappropriate use of that data. Appropriate use deals with improving process performance, while an inappropriate use of measurement data could involve an individual's performance. To be effective in providing useful measures and support productive management decision making, the dedicated, hardworking individuals must be confident that an automated defect prevention system will be used for the benefit of the entire team.