Customer Reviews

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

5 star:		(5)
4 star:		(3)
3 star:		(1)
2 star:		(1)
1 star:		(0)

 

 

One of the oldest dilemmas in software development has been "Is software development art or science?". Of course, it's neither, but the science and engineering mindset has generally held sway, and deviations from this approach have been treated as aberrations, to be eliminated so that we could be more 'scientific'. But what if that's the wrong direction?

Roy Miller explores the origins of the scientific/engineering/manufacturing mindset in software engineering, and then goes on to suggest reasons why this metaphor might not be appropriate for modern software development. He weaves strands from a number of disparate disciplines, including biology and chaos theory, to suggest alternative approaches to software development. Multi-disciplinary approaches are a common theme in modern scientific research, and it's good to see someone bringing these influences to software development.

Roy's fundamental message (and he of course justifies this in detail), is that if you're looking for predictability in software development, you better get over it. Software development is a messy, human endeavour, and if we keep doing what we did, we'll keep getting what we got. Roy suggests alternative metaphors and approaches that might be more succesful in growing software.

I see that at least one other reviewer has commented that the Taylorist manufacturing mindset can be applied successfully to software development. Even if that's true, it doesn't make it the only game in town, and it's worth reading Miller's work for an alternative. My own experience suggests that the Taylorist manufacturing model only works when a software project is large enough to make individual human differences irrelevant, and that projects of that size are becoming less common, and generally fail anyway.

Read this book, even it it makes you uncomfortable or doesn't change your mind. You'll gain at least one new idea, and that's worth the price of admission.

I read thru early review drafts of this book made available from the yahoo-group website for the book. What I liked most about it is that it was able to successfully convey to me not only the "manufacturing mind-set" it describes (in contrast to agility), but it also conveyed the foundations of that mindset and why it is held by so many in the industry. I never really had a good enough appreciation for that until reading this book.

I think the book also does the same "justice" to the agile-mindset for "growing" software thru "emergence". It describes the foundations of agility and emergence, where they come from, what they mean, and what evidence there is and isnt for their validity.

The book touches on elements of Taylorist management theory, as well as complexity theory in an approachable manner that doesnt require an advanced degree in math or physics (which is a plus :-).

I also particularly like the annotated biliography at the end of the book. It lists more than just the titles of the "giants" the author stood upon to write this one, it excerpts and distills the key central concepts from each one that are relevant to the book.

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

This book starts by describing how Taylor's Scientific Management has lead us down the incorrect road of thinking software can be managed like steel manufacturing. The author does a great job of presenting these fundamentals and presenting the conclusion that a new model for thinking about software is needed.

To find an alternative model the author draws on ideas from complexity science. He presents the idea that we need to think of software as growing rather than something we control if we can just add one more level of detail to our Gantt charts. If we think of software as emerging from the environment in which it is started we can exert influence on the growth of the software so that it grows toward our goals. However, we still can't control it like we can control steel manufacturing or an assembly line.

An earlier reviewer has commented that there is much to disagree with in this book. I think the author of the book would scream "Yes! Exactly!" Of course there's much to argue and debate with in this book. The book is full of original thinking and is proposing a radical shift in the thinking of most software professionals; that is bound to stir up debate and some disagreement.

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.

Before adding my two cents, I must state that I previously co-authored a book with Roy Miller and have worked with him for almost three years. However, Roy wrote this one on his own and I receive no financial benefit from the sale of this book.

I recently read this book from cover to cover... it was hard to put down. The author exposes the idea proffered by many explicitly or implicitly that software production should be treated like a manufacturing process for what it is... a lie, falsehood, misconception, and/or misapplication-of-theory.

But he doesn't just say that. Anyone can casually say that, and many have. They might even get some others to agree with them. But the agreement is often shallow and those who nodded in the affirmative usually walk away unchanged. This book exists to make sure that doesn't happen if the reader stays tuned in through the entire book.

Drawing upon experience, research, and thorough reasoning, the author suggests:
* the original mental model (optimization theory) and where it came from
* why this mental model, when applied to software development, is wrong
* a new series of mental models we can use to explain how software development must be
* suggestions for what to do with the new mental model and how to apply it to increase the effectiveness of software development.

The author states that many will reject this book. It's full of what many don't want to hear in the first part of the book and it keeps hammering it home from a variety of angles. I challenge all IT managers to have the intestinal fortitude to stick it out and read through it. Then give it to everyone else in your IT management chain.

Hopefully, you'll stay tuned in through to the end and it will make the world for both managers and the developers under them a better place... not to mention saving companies a lot of money that they currently throw away due to painfully wrong management techniques.

Complexity Science has been applied previously to software management by (at least) two leaders in software develoment: Jim Highsmith and Mike Beedle. Roy's book delves even further into the topic of complex adaptive systems, using it to expose the myth of prediction and control in the inherently complex process of software development. An entire chapter is spent introducing readers to the ideas of complexity science. The rest of the book builds upon the concepts of complex adaptive systems and eventually applies them to agile software development.

Roy's coverage of the manufacturing mindset the software industry inherited from Frederick Taylor was enlightening. It exposed the assumptions that many software development managers hold and placed them in a historical context.

"Managing Software for Growth" fundamentally changed the way I perceive software development projects. Although I was quite familiar with the principles of agile software development, Roy's book takes us a step further toward understanding why these principles work.

Expertly written by Roy Miller (a team lead and XP coach at RoleModel Software with over 10 years of information technology experience), Managing Software For Growth: Without Fear, Control, And The Manufacturing Mindset is an instructional guide designed especially for IT professionals searching for means to improve efficiency in software development projects -- almost 75% (according to recent surveys) of which are over budget, late, undeliverable, or simply canceled. Individual chapters address an overview of issues affecting software program development managers, from uncertainty to the risk of losing control to using and not falling prey to the power of one's own mindset. Managing Software For Growth is a very highly recommended primer and general tip guidebook and manual.

There are some things in this book that are very good, but the main punchline fails to deliver. I'll highlight the ups and downs below.

Good Stuff:

The author does a good job of explaining Taylorism, why it works for manufacturing, and why it doesn't work for software. Taylorism assumes that a problem is predictable, controllable, and therefore needs mere optimization. Software does not fit this mold.

Another thing that the author presents well is the lack of silver bullets. He presents his material as a "lead bullet" and warns against hype. This is not new or novel, but something that we need to be reminded of. He also admits that agile methods have their faults, but suggests that they are a better approach than the traditional manufacturing based software methods.

Bad Stuff:

There's really no other way to put it than the author goes way out in the weeds for his main premise to support growing software. He bases his arguments on complex adaptive systems as applied by Stuart Kauffman to biological evolution. This is a theory that cannot be proven, and an odd metaphor to apply to software development. However, I will let the author himself give the most incriminating testimony:

"Regardless of whether or not Kauffman's hypothesis is true for biology, the idea holds interesting possibilities for human interaction in trying to solve messy problems."

Miller spends the entire chapter outlining Kauffman's theory only to say in the end that it might not be true.

There are much better works on taking an alternative approach to software development that lack the flaws of this book. Give Pete McBreen's "Software Craftsmanship", Tom DeMarco's "Slack" or Poppendieck and Poppendieck's "Lean Software Development" a try instead.

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.