After reading Scott Vokes’s intriguing post about the importance of Problem Solving Like a Generalist, I asked him: “Hey what’s that little book on the top of the stack in the picture?” His enthusiastic response (and the ridiculously low price on amazon) led to a knee-jerk, buy-it-now response.
Systemantics: How Systems Work and Especially How They Fail was more thought provoking and rewarding than I could have possibly imagined. This book isn’t so much about making Systems work, but about how Systems invariably don’t work, due to several underlying laws and principles of the universe. And, what’s a System? Examples given in the book range from economics, government, and business to engineering, research, and programming. To read this book is to get a better understanding of fundamental axioms, theorems, and principles that underly the humanity around us.
Some of the book’s core axioms include:
- Le Chatelier’s Principle: The System tends to oppose its own proper function.
- New Systems generate new problems.
- The Generalized Uncertainty Principle: Systems display antics (thus System-antics, haha).
- Functionary’s Falsity: People in Systems do not do what the System says they are doing. (one of my favorites)
What was most interesting to me was how the principles presented in this book apply to my own experiences in the corporate world and how Agile attempts to resolve malfunctioning Systems. I think that anyone who has had similar experiences in the corporate world would appreciate the hilarity and futility of the axiom: “Systems attract Systems-people,” and that “Efforts to remove parasitic Systems-people by means of screening committees, review boards, and competency examinations merely generate new job categories for such people to occupy.” As you can see humor and pessimism is a common theme in this book.
One of the axioms clearly applies directly to programmers and Test Driven Development (TDD). It is: “A complex System designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple System.” The problem with implementing a large System design is that “the crucial variables” have not yet revealed themselves. These variables can only be discovered by failure, and this is where testing comes into play. Testing accelerates the pace of failure and, thus, the pace of “working” System development.
In general the book has given me a better grasp of the impetus for the values of the agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
What’s astounding is how old this book is and how relevant and applicable it remains. At no time did I feel like the book was dated or obsolete. I think this proves the value and profundity of the ideas it presents.
Also, since I don’t have a tremendous readers attention span, its brevity and density was much appreciated. The author (John Gall) submits that what follows is deliberately brief, simple, and austere.