Ola Ellnestam - The Mikado Method

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact

Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 261 Shelter Island, NY 11964 Email: orders@manning.com

2014 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Recognizing the importance of preserving what has been written, it is Mannings policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.

Manning Publications Co.20 Baldwin RoadShelter Island, NY 11964

Development editors: Cynthia Kane, Frank Pohlman Copyeditor : Andy Carroll Proofreader : Katie Tennant Typesetter : Gordan Salinovic Illustrator : Martin Murtonen Cover designer : Marija Tudor

ISBN 9781617291210

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 MAL 19 18 17 16 15 14

Most software discussions, books, and articles seem to assume that development work starts with an empty codebase. The Agile literature usually presumes that the detailed learning about what is needed to solve a problem for a stakeholder community can be discovered iteratively and incrementally. This might be a valid assumption if one is starting fresh, but I seldom encounter teams with the opportunity of starting from scratch; there are always constraints. Most investment in software today involves modifications or extensions to existing applications and environments. Thus, in addition to discovering and implementing solutions to our organizational problems/opportunities, we have the constraint of fitting into the environment created by earlier development teams. We need to discover and codify not just the applicable domain knowledge, policies, and organizational goals that drive our current development work, but also to understand how the changes we make affect the existing application environment.

Everyone who has done this kind of work knows that the information we need is only weakly represented in the documentation left behind by preceding teams. One has to look at the source code to get reliable information about the constraints it imposes on additions and changes. If the source code includes an effective set of automated tests, were in luck because tests illustrate the behavior required of the code by previous implementers to solve previous problems. If these tests pass when executed, we know that the code behaves as they expected. More often, automated tests were never created, and were left with only the source code itself. The question then becomes how to learn what we need to know to avoid breaking previous work.

The barrier is sheer complexity. Analysis of the preexisting code has proven to be a weak tool for tackling this complexity. Much of the code we have to confront no longer communicates effectively to us the nuances we need to understand to avoid breaking it as we implement our changes, and it usually ends up taking far more time than we can afford. Therefore, after we exhaust our patience with analysis, were forced to go ahead and take a chance at breaking the fragile existing code. What we do next is critical.

Traditional approaches have ended with a long, tedious, unpredictable, test-and-fix period that often consumes the second and sometimes third 90% of our project schedule. Agile and lean thinking have taught us to test immediately, integrate continuously, and fix every problem as soon as we discover it. This works well with well-structured code thats weakly dependent on its environmentprovided we have an effective automated test suite. The teams who preceded us, however, have seldom had the perspective, skills, or inclination to leave us with such a foundation, because they were driven mostly by the need to get-it-done (project scope focus) even at the expense of keep-it-clean (longer-term product lifecycle focus). So we find ourselves in a hole!

The first rule of holes is this: When you find yourself in a hole, stop digging! Agile thinking suggests that for all the code you add to an application, you should use your refactoring, clean coding, and TDD practices to ensure that you dont make the situation worse. Youll probably have to add some higher-level automated functional tests to be able to do even this safely. Even then, complexity easily becomes overwhelming, and quality, speed, and cost all suffer. Managing this unavoidable complexity is what this book is about. Rather than permitting complexity to cascade, The Mikado Method enables you to discover what you need to know and address it in manageable pieces by maintaining your focus on always having a known good code base. Ultimately, this is the deepest core of Agilealways ensure that the work you have done so far is correct.

While the form of the Mikado Method is simple, its tied closely to and greatly helps with the application of principles and practices weve learned over the last decade. It addresses individual, pair, and team-wide practices to reliably tackle changes in small steps. Ubiquitous language and the SOLID and DRY principles characteristic of clean coding practices guide our Mikado Goals and the trees of prerequisites that structure our work. Mikado Graphs help keep our packaging, dependency, TDD, and refactoring work properly focused.

The initial focus of the Mikado Method is effectively dealing with a messy reality. The long-term goal, however, is to understand the forces that drive organizations to create bad code in the first place so we can avoid creating more code that our successors will have to struggle with unhappily. When were confronted with the normal levels of complexity in todays software, we cant keep everything we need in our heads at once. People have discovered many ways of effectively working together in complex tasks, starting with the scientific method and extending to the Theory of Constraints, empirical control systems, and pull/flow systems. The Mikado Methods approach works with all these strategies to help us stay in control.

T OM P OPPENDIECK

We once worked on an application that was used to configure the behavior of a specialized electronics module in an expensive hardware product. Our application was a part of the delivery of that product. One day, news reached our software development team that Sales had unexpectedly landed a contract with a new client. At first we didnt know what to make of it, but in time we learned that the new client needed a version of our application that was almost identical to the one we had. This was fortunate. But after further investigation, we realized that there were certain parts of the application code that under no circumstances could be shared between the new client and our old ones. We had to come up with a solution to this problem, or we couldnt deliver to the new client at all.