Doug Durham and Chad Michel
Lean Software Systems Engineering for Developers
Managing Requirements, Complexity, Teams, and Change Like a Champ
1st ed.
Logo of the publisher
Doug Durham
Lincoln, NE, USA
Chad Michel
Lincoln, NE, USA
Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the books product page, located at www.apress.com/9781484269329. For more detailed information, please visit http://www.apress.com/source-code.
ISBN 978-1-4842-6932-9 e-ISBN 978-1-4842-6933-6
https://doi.org/10.1007/978-1-4842-6933-6
Doug Durham and Chad Michel 2021
This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
This Apress imprint is published by the registered company APress Media, LLC part of Springer Nature.
The registered company address is: 1 New York Plaza, New York, NY 10004, U.S.A.
To my wife, Shana, who continually encourages me and fills my life with love, laughter, and happiness, and my father, Howard Durham, who showed me the importance of doing things the right way.
Doug
To my wife Lisa, my son Sam, and my daughter Eva for all the support and encouragement during this endeavor.
Chad
Foreword
In life, good systems are better than goals. Regardless of how dire things are, it is better to have a system that allows you to keep improving and eventually attain your goals than it is to have obtained such goals but without any way of sustaining such success. I would argue that good systems are behind every success story you have ever heard about, be it of an individual, a company, or a product. Examples for the principle that good systems are better than goals are at every scope and task. For example, most people can get on a diet and lose some weight. At the same time, most people regain the weight (and then some) when they go off that diet. The key to permanently losing weight is to change your lifestyle, preferences, daily routine, diet, and even thinking process. In short, obtaining a better system. Which new developer would you rather hire? An experienced developer that knows the specifics of the technology at hand but is argumentative, avoids learning any new technology, and practices what that developer is already good at; or a developer that has little experience and does not know the current technology, but has a great can-do attitude, is eager to learn new technologies, to help teammates, and who cares deeply about quality? The reason you prefer the second developer is because that developer has a better system. It is even better to have a development process that reduces complexity and rework with good design, a process that accommodates quality control activities, and has zero tolerance for defects once found than it is to have a target of zero defects.
Perhaps the most extreme case of systems vs. goals is the upstarting Japanese automobile manufacturers and the established US automobile manufacturers in the years after the Second World War. In 1945, after several years of strategic bombing, Japan had no currency, no roads, no bridges, no power stations, no telephone lines, no factories, no cities, and no men. At the same time, the United States was the only advanced economy that survived the war unscathed. At the time when the Germans lived in rubbles and the British rationed food, the Americans were at the top of the world with their industrial and agricultural base operating at full capacity, with the reserve currency of the world, and millions of people ready to get back to work.
In 1947 Edward Deming (having given up on trying his techniques in the United States that was resting on its laurels) moved to Japan and started sharing his ideas on all aspects of manufacturing such as quality control, process, design, feedback loops, management, organization, and supply chains.
By the early 1950s, Toyota and Honda started adopting Demings system and evolved it into what we now call just-in-time lean manufacturing. They transitioned from actual manufacturing into a process of continuous integration of ready-made components into any conceivable car. This enabled much better market segmentation due to the customization of the products. In fact, this was a level of variance that was unheard of, while maintaining a very fast response time to changes in the market. The new system did require a new grade of workers who were generalized specialists and could perform any of the tasks on the factory floor as the need arose. The system required the workers to own the process, to be familiar with every aspect of the factory, to collaborate in daily stand-up meetings on the objectives, to monitor the burndown rate of components, and to divide the work using the Kanban board. The new system eliminated inventory cost at both ends, at the factory and at the dealers, which in turn drastically reduced the final price. The most important aspect of Demings idea was total quality management, where any worker was a quality vigilante, watching the process like a hawk with a relentless commitment for eliminating defects. The result was the best cars, at the best price, with the most customization. At the same time, this feat of engineering did require composable design of the assembly line to be able to assemble any car while not designing against any car in particular, flawless design of every artifact in the car, especially designing the components for reuse, and accurate calculations of the cost and schedule of every element (this process inspired Agile development).
By the 1960s the Japanese carmakers started dominating the US market, while the American car manufacturers stuck to their old systems. By the 1970s, the American car industry was finished.
Software development is nothing more than manufacturing code. This manufacturing should be impeccable as far as quality, must easily respond to changes, be done in the fastest possible way, at the lowest cost, and avoid unmitigated risks.