Managing Software for Growth: Without Fear, Control, and the Manufacturing Mindset

Rating:
Summary: Much needed work for professionals
Review: This is a very important work that helps the software industry to take much needed steps to gain reliability and authority again.
As software development is unique, due its many singularities in people management, processes, design methods and tools, Roy Miller point us in a very sensible direction accordingly to software development realities.
This is a very important work for software development professionals to get skill

Rating:
Summary: Excellent Book
Review: This is THE book I recommend to clients who are hesitant to use an agile approach in developing software. It's an excellent book for both managers and developers.

Rating:
Summary: Excellent Book
Review: This is THE book I recommend to clients who are hesitant to use an agile approach in developing software. It's an excellent book for both managers and developers.

Rating:
Summary: Much to take issue with
Review: When reading this book, there are some points where I agree with the author, but there are others where I strongly disagree with what he says. There is no question that a managerial style that relies on fear and intimidation of the underlings is counterproductive. Similarly, a schedule that relies on programmers putting in ten hour days for weeks, or performing "heroic" actions is ridiculous in general. These points have been made in many places, so their appearance in this book does not differentiate it from many others.
Miller also spends a great deal of time in arguing that the principles described by Frederick Taylor that led to the tremendous efficiency of the manufacturing assembly line cannot be applied to software development. Here, he is only partially correct. Yes, it is true that software development has historically been considered an art rather than a science. However, a large amount of effort has been expended over the last decades in converting the often ad hoc methods of software development into a discipline of software engineering and making the term computer science one that accurately describes the discipline. Areas such as design patterns, development tools, the Unified Modeling Language (UML), reusable component development and the other principles of software reuse are all strategies designed to make software construction more organized and efficient. In other words, more like manufacturing. Without these advances it simply would not be possible to create programs with millions of lines of source code.
He also ignores the recent trends in manufacturing towards the custom creation of a product based on the order of a single customer. Many manufacturers now have their manufacturing principles so refined that they can take a custom order in the morning and ship the product before the close of business that day. Therefore, his arguments against the manufacturing approach for software development uses many principles of manufacturing that are outdated.
I recently read the book "Five Core Metrics: The Intelligence Behind Successful Software Management" by Lawrence H. Putnam and Ware Myers, published by Dorset House. Their main theme is that if statistical methods are used, it is possible to make reasonably accurate predictions concerning the time and effort needed to complete a software project. They also back up their claims with sound mathematical reasoning and some historical data. With accurate metrics to guide you, it is possible to move software development towards a modern manufacturing structure.
Miller also spends some time discussing the principles of chaos theory and how it applies to software development. While it is true that chaos theory allows for the possibility that "A butterfly flapping its wings in Iowa today can cause a tornado in Moscow next month.", this presupposes that there is not a comparable butterfly in Missouri where its wings flapping negates the actions of the one in Iowa. Chaos theory simply does not strictly apply to software development. Chaos theory assumes that the system is not consciously guided in any way, so that small changes create small problems that cascade into big ones. Development teams can constantly monitor their situation and move to make alterations to eliminate any problems that are starting to grow into big ones.
Finally, Miller constantly refers to the action of growing software without defining precisely what he means. He uses several analogies to biology and the ideas of evolution. With very few exceptions, software is not grown like a biological organism, but constructed from preexisting code, with modifications done only when necessary. The modern software developer is more of a sensible aggregator and integrator than a creator.
In conclusion, I strongly disagree with many of the points made by Miller in this book, believing that his arguments go against many of the trends in the software world today.