The Mikado Method (2014)

Part 1. The basics of the Mikado Method

Chapter 4. Organizing your work

This chapter covers

· Changing at scale—small, medium, and large

· Working alone, in a pair, or in a team

· When to start drawing the graph

· How to combine working with new features and structural improvements

Imagine one day you’re happily starting work on a part of the system you haven’t looked at before. You have a new requirement for the user interface that shouldn’t be too difficult to implement. But as you begin, you realize that there’s an issue with the inheritance hierarchy in one of the core components you need to use. You call in a coworker and tackle this together. Digging a bit deeper, you find that the constructor of the base component is making assumptions and calling methods that might not be ready to call in the constructor. Making matters worse, there are dependencies going back to the very initialization of the entire application. You realize that fixing this will affect a substantial part of the system.

You and your colleague decide to bring the matter up at the team’s morning meeting. The senior tech starts looking uncomfortable and says, “That code was written a long time ago by some guys who weren’t very knowledgeable in object-oriented programming...” Your team has lived under the assumption that the code was in better shape than it actually was, but now you can’t do that anymore, and it will affect the whole team’s work. It’s time to roll up your sleeves. But now comes the tricky part. Now you need to fix the problem and communicate what needs to be done to everyone who’s affected, and do it as you’re making the change.

There are a few ways in which the Mikado Method can help here:

· It can help you get an idea of how big the change is—we’ve already discussed how the Mikado Method can make changes of any size more manageable (even though it gives the most benefit when applied to medium- to large-scale improvements).

· It can help you communicate and keeping track of your work regardless of how many people are working on the project—whether you’re working alone, in pairs, or in groups.

· It can help you decide where to put the development focus in a team setting—whether the workforce should focus on new features and restructure as needed, or focus only on structural improvements, or a combination of the two.

In this chapter, we’ll look at how you can approach problems of different sizes, with different levels of staffing. Let’s start with how you can get an idea of the scale of a problem.

4.1. The scope of a change

The single, most telling sign of the scope of a change is the size of the Mikado Graph. If the graph contains less than a dozen nodes, and the content of each node is relatively fine-grained, we consider that change to be small. Fine-grained means smaller refactorings, like “Introduce parameter,” “Change method signature,” and the like. If the graph contains more than a dozen nodes, or if the prerequisite nodes include more work than two to four refactorings each, it’s a sign that the change is quite big. Coarse tasks or big graphs (or both) indicate a medium-to-large change and a lot of work.

Of course, when the graph doesn’t grow anymore, you’ve found the prerequisites, which is the major part of the work. Hence, to estimate how large a change is before the entire graph is complete, you usually have to get a feeling for how much the graph is growing and assess your prerequisites, in order to guess how big the change is getting.

4.1.1. Changes at different scales

Different scales of changes require different approaches, but changes usually start small, and some continue to grow. If you compare graph sizes for small, medium, and large changes, you’ll find that large changes take a disproportionally longer time—a graph with twice as many nodes is likely to take more than twice as long to work through. As a result, we structure our work somewhat differently when we tackle larger restructurings.

Let’s take a look at changes at different scales so you can see how the Mikado Method fits in and see what the turning points between small, medium, and large problems look like.

Small-Scale Improvements—Minor Adjustments

Small-scale improvements are those on the scale of a method or a class, where the consequences of making changes mostly stay within a handful of lines of code. You can make these changes continuously as the code is read, or before implementing new features. When readability is improved, benefit comes almost instantly, and others who follow will benefit too. The book Clean Code by Robert C. Martin (Prentice Hall, 2008) has plenty of advice for dealing with these situations, and the behavior we’re describing is sometimes referred to as the Boy Scout Rule: “Leave the campground cleaner than you found it.” In reference to code, that becomes “Leave the codebase in better shape than you found it.”

Small improvements include improving naming, removing minor and obvious duplication, and deleting unnecessary code, to mention a few. These are the types of flaws that can be remedied in seconds with a modern IDE, usually by using an automated refactoring.

Unless you use a dynamic language or a dynamic feature like reflection, the compiler will tell you if something went wrong. Regardless, it’s wise to have some sort of safety net while performing such changes, like a suite of automated tests. This suite should be so fast that you can run it after every change, no matter how small the change is. If it takes longer than a couple of seconds, the value of the test suite is reduced dramatically, and chances are that it becomes more of a straitjacket than a safety net. When you use a dynamic language or dynamic features, that safety net is a lot more essential.

Even if a change is tiny, like renaming variables and methods, you should make sure that it’s backed up or checked in to a versioning system as soon as possible. This way, nothing is lost, and all those small improvements can be kept in the event that a rollback of something bigger is unavoidable.

Cleanups are more or less ad hoc and usually have few prerequisites, so the Mikado Method doesn’t add much value at this low level. Small-scale refactorings have a lot to do with clarity, and problems tend to surface as the surroundings get less opaque. When you slowly remove dirt and mud from your code, the need for larger repairs becomes more apparent. It’s almost as if the code talks to you, thanks to all these small refactorings. The discovery of medium-scale improvements often begins with small improvements, and this is a good reason for you to engage a lot in small-scale refactorings.

Medium-scale improvements

Medium-scale improvements typically involve a handful of classes. Some examples are replacing a wild-grown conditional with polymorphism, replacing an implicit tree with the composite design pattern, or splitting up a single class that has too many responsibilities into several classes. Another example would be fixing awkward usage of abstractions, or a part of a design that’s disintegrating under changing requirements.

In addition to discoveries made when doing small-scale refactorings, medium-sized changes also come from the itchy feeling every time you visit a set of classes and think there must be a better way of doing this. Often there is.

Medium-sized changes usually take one or two developers anywhere from a couple of minutes to a day or two to perform, depending on the size and the number of classes or responsibilities involved.

This is where the Mikado Method starts to become more useful and adds value. If you’re struggling to understand where you should start using the method, this is where we recommend you start. Here you can learn how to use the method and get real benefit from it at the same time. It can be quite powerful when interruptions are common and you want to get back to your train of thought quickly.

When you start pulling in medium-scale problems, and other problems keep popping up, and things get really messy, you’ve probably found a large-scale problem.

Large-scale improvements—major overhauls

A large-scale improvement will lead you to change several parts of a system. This is the true essence of a structural improvement, where you break up heavily entangled code and mazes of dependencies, extracting APIs from what weren’t meant to be APIs, and dealing with the ripple effects of a large change.

Often, there’s an external goal and a bigger vision connected to these kinds of changes, and that will result in a lot of work. Other times, large improvements are the result of a rotting design that has reached its breakdown point. In addition to the challenge of doing the work itself, it’s also hard to estimate the complexity and size of large changes like these, so it can sometimes feel like you’re never going to finish your improvement.

When large portions of the code are changed, your whole team and those around it who are affected will all have to be engaged. Everyone needs to know about the goals to be able to help out and understand. The team has to communicate outside of its immediate vicinity, especially when the change is because of an internal issue, such as an old design that has reached its breaking point.

All things considered, this is the perfect situation for the Mikado Method. As the code undergoes massive changes, work is generally spread out over several days, weeks, or months, and can benefit a lot from being carried out by several developers on a team. Putting the Mikado Graph on a whiteboard during this period of change is a great way to communicate that goal and the progress, and to spur conversations about the code design of the solution. External stakeholders, managers, and other people interested in the progress are also more likely to get involved if they can see what’s happening.

The power of visualization

A picture is worth a thousand words, and a Mikado Graph is worth more than a thousand to-dos. We remember a project where the whiteboard with the graph was visible to everyone because we kept it in the team room. This sparked more questions about design and more action than the all the to-dos we had ever written in the codebase and all the design documents we composed.

4.1.2. When do I start drawing my graph?

As we said at the beginning of this chapter, it can be hard to know that you’re getting into trouble when you start working on a problem. Small graphs don’t take a lot of time to draw, but there’s always a balance to strike between the overhead of the process and the benefits. For day-to-day work, we’ve developed a simple rule of thumb, which we call the third-level tactic.

The third-level tactic rule says that you can keep the dependencies in your head as long as there’s only a goal and one level of prerequisites, which roughly translates to a to-do list of independent items. As soon as it gets more complicated than that, draw a graph on a piece of paper and continue working with the graph until the problem is solved. If the graph stops expanding quickly after you’ve just drawn it, congratulations! You have a fairly simple restructuring ahead of you. If it doesn’t stop expanding, that means you have a medium-sized or larger change ahead of you. In that case, be glad that you started drawing the graph early on. And by all means, if you want to draw a graph from the very start, please do. This approach is a bit more dogmatic, but it also gives you a nice representation of a to-do list, and you’re all set if things turn rough.

Figure 4.1. Third-level tactic

In reality, taking on a big change is rarely something you’ll decide to do on a whim. That decision usually comes after long and careful consideration. Sometimes the decision matures slowly after an insight about the codebase, such as if you realize there needs to be a type for InterestRatein the financial codebase, instead of just in a number in calculations. This requires the transactions to be in a certain format, thereby creating ripple effects through the codebase. At first, it might feel like a lot of work, but as the idea matures, and you see all the places that would benefit from the restructuring, the benefits might outweigh the effort.

Not only do all changes look different, they can also be approached differently. In the next section, we’ll discuss using the Mikado Method as a single developer, as a pair of developers, and in a team.

4.2. How to approach a change

You already know the mechanics of the Mikado Method approach. Now it’s time to learn how and when you can share your work to make it easier. Sometimes you’ll have the luxury of working in a team, and sometimes you’ll be on your own. Table 4.1 is a summary of the particular benefits of using the Mikado Method in some common constellations in software development. The following sections will explain this in more detail.

Table 4.1. Benefits of using the Mikado Method in different constellations

4.2.1. Working in different constellations

Let’s say you’ve realized that you’re up against a big change. You need to introduce that InterestRate concept after all, and it’s all over the codebase. But should you make the change now, all at once, by yourself, or should you bring it up with the team (if you have one) and make it a team effort? Both could be valid approaches for a problem, depending on the circumstances.

Distance yourself using the graph

Working as a single developer on a project has its advantages and disadvantages. The big advantage is that you are the team, and you make the decisions. On the other hand, no one will be there to critique your work or help you reflect on what you’re doing. That’s up to you, and the Mikado Graph can help you zoom in and zoom out on the problem. During and after your work, you can always take a step back to look at the graph. By doing so, you get a chance to reflect and possibly modify your strategy and tactics.

Maintaining your graph

Writing clearly in the nodes of the graph and being precise might not feel important at first, but coming back to a messy graph even after a short break can add significantly to the already cumbersome work of restructuring. When you’re working alone, you should try to keep the graph in the same condition as you would if it was a shared one.

When you’re on a team, you have the choice of working alone on a problem, but that should be a last resort. If you can, try to partner up when solving a problem that’s large enough that you need the Mikado Method. You’ll get the support, the different point of view, and the knowledge and experience of the people you work with.

Pairing

Pair programming is a practice propagated by development methodologies such as Extreme Programming. Normally, when you pair program one person, the driver, is in charge of the mouse and the keyboard, and that person writes the code needed. The other person, the co-driver, helps the driver by keeping track of what they need to do next, proofreading the code, and being constantly alert and ready to take over driving when it’s time to switch. Switching from driver to co-driver should occur fairly often, to keep you from getting stuck in a rut.

While the driver focuses on going from ideas to actual written code, the co-driver can stay at a higher level of abstraction, keeping the big picture in mind at all times. The abstraction level of future design is more aligned with the whole graph, and the tactical decisions of programming are closer to the single nodes of the graph. The driver focuses on how and the co-driver updates the graph and decides on the what and when.

Because the co-driver doesn’t need to focus on the nitty-gritty details of the code and has both hands free to draw, the co-driver is best suited to update the graph. Because the roles switch back and forth during pairing, some extra effort is needed to make the Mikado Graph readable for the both the driver and co-driver. The graph needs to be explicit enough for either of the pair to continue the work where the other left off.

Working as a team

A team can also use the Mikado Method to coordinate ongoing redesigns and refactorings. When you do, you’ll want the Mikado Graph to be put in a place where everyone can change it and see it, such as on a whiteboard in your team room.

Putting the graph on a whiteboard sends a signal to the team. There’s a visualized goal and there’s a path to get there. It’s collectively owned, and anyone is allowed to change it and collaborate around it. This gives everyone the opportunity to contribute by expanding, changing, or questioning the graph.

When you have a visual representation of the goal in the form of a graph, it’s easier to spot when a decision is in direct conflict with that goal, or if a decision is taking the code in the right direction. A collectively owned Mikado Graph can also double as a visual task board and bring the whole team closer to a mutual understanding of what they’re doing. To increase its effectiveness, it’s important that all team members be able to quickly understand what the essence of a node is, which makes an early agreement on the granularity of node content all the more important. Let your team decide how explicit and detailed the information in the nodes of the graph should be, and stick to that level of detail during the lifetime of the graph.

Large-scale restructurings or refactorings—the kind where the Mikado Method is especially helpful—should start by communicating within the team and then spreading this information to the rest of the organization. Because this kind of work often affects larger areas of the system, there may be conflicts with the work other people are doing. This is why large, unannounced, single-person refactoring raids scale poorly.

When you work as a team on a restructuring, you need to decide on how to split the team’s focus between adding new functionality and embarking on structural improvements.

Mob programming

Mob programming is “all the brilliant people working at the same time, in the same space, at the same computer, on the same thing.” (mobprogramming.org)

The easiest way to work with the Mikado Method and restructure a system in a team is by mob programming. Mob programming means having a single computer connected to a projector (or two), and everyone in the room watches the screen, helping out as you work on one thing at a time. The team members take turns at the keyboard, switching at regular intervals. The team jointly updates the Mikado Graph as the code reveals its secrets, and everyone in the room is as up to date as can be. The rest of the team can also contribute in other ways, such as searching for helpful information.

This is a very good way to get a common understanding of the problems in a system, to decide how to solve those problems, and to get acquainted with the Mikado Method or some other knowledge that might be unevenly distributed in the team. Some teams work in a mob all the time, on all of their development. You can take that approach, or you can use mob programming when you’re starting out, to get a common point of view before splitting up to work in parallel. You can always resort to mob programming at a later stage if you run into a tricky problem, or if you have something that you want to share.

Distributed teams

Sometimes, your team isn’t situated in a single room. On those occasions, try to find a tool that’ll allow everyone to view and modify the Mikado Graph, preferably in real time, and that’ll allow several users to simultaneously update the graph. In addition, it’s good to have a teleconferencing system, or the like, in place for verbal communications. In the end, the needs of the team will determine what solution you choose. A good rule of thumb is to start with the simplest solution possible, and then update when there’s a need to do so.

As always with distributed teams, more time and effort must be spent on communication, in this case around the creation and evolution of the Mikado Graph.

Graphviz—a low-key graphing tool

A very low-key, and free, graphing tool to use for sharing graphs is Graphviz (www.graphviz.org). Its simple text format makes it ideal for storing and sharing graphs in a versioning system, as opposed to binary image formats or other proprietary document formats that require a tool to edit. We used Graphviz to generate the initial drafts of the graphs for this book during writing.

Guide for problem size and constellation

Your problems won’t always be big ones. Table 4.2 illustrates some of the possible benefits of the Mikado Method in different constellations and for different sizes of problems.

Table 4.2. Main uses of the Mikado Method depending on constellation and problem size

4.2.2. Where to put the focus in a team

Now you have an idea of how and when to use the Mikado Method in different constellations and for different scales of problems. As you can see, when you work in a team, you have more ways of organizing yourself and the work around changes. Parts of a team can work on new features, improvements, bug fixes, performance optimizations—this is something that a single developer can’t do without task switching.

With the option of having parts of a team work on different types of tasks comes more questions:

· Should we split the team?

· What should we focus on?

A very important step of the Mikado Method is to select the goal, or goals, you’re going to work with (see figure 4.2). There are two main categories of goals to work with: new features and structural improvements. A new or augmented feature can be used as a goal, perhaps in the form of a use case or user story. Large features and the Mikado Method work best together if they’re broken down into subcomponents as a first step, and then each of the subcomponents becomes a new goal. This way of working keeps the information about the features and the refactorings in one place, namely, the graph. Be careful, though, when you break up features; each goal must be able to stand on its own.

Figure 4.2. Selecting a goal

For new features or changes, the goal can be formulated as it normally is in a user story or requirement that ties it back to the business value of the work, so non-technical people can read the graph and get an idea of what’s going on. For instance, “Replace hardcoded implementation with a pluggable architecture to add new services faster at lower risk,” or “Replace XML configuration with code to simplify code navigation” speak to both the developer and the non-technical person.

For improvements that are mainly inward facing (very technical), we suggest reconsidering the outcome and looking at it from a business perspective. A goal that suggests replacing a custom-made framework, or an overhaul of the entire persistence architecture, isn’t going to persuade non-techies, so formulating the goal in non-technical terms generally yields a better response. If you can explain how the organization benefits from an improvement in terms of an increased return on investment, a positive cost benefit, or a reduced risk, the discussions with the people who pay for the system will be a lot smoother. Still, taking on a large change that’s the magnitude of an architectural overhaul as a single goal might be too much. Such large changes can require some additional planning and communication before they’re started.

Now, how do you select tactics? Let’s look at some different ways to focus your work in a team.

Focus on new or improved features

One way of working with a team is to focus on implementing new features, and to restructure parts of the code only if they pose an immediate problem. Imagine you have a server handling loan applications, with an apply service, a query service, and an approve service, but they’re all mixed together in the same class. Let’s say you have a feature request to move the apply service to a public server (this is the example you’ll see in chapter 5), so you need to extract that part so it’s deployable on a separate server. You could create a pluggable architecture and split out all the services, but in this case you can focus on doing only what is absolutely necessary. This makes it easier to get acceptance for structural improvements, because they’re tied to a clear business value.

By using features as goals, growing the graph if need be, taking on as few goals as possible at a time, and trying to finish the goals as soon as possible, business value is maximized. This way of working greatly reduces the risk of spending time on things that won’t get done, or that shouldn’t be done in the first place.

So how much should you restructure? As a rule of thumb, you should be more eager to restructure when you have a good relationship with the people paying your salary, when you know it will pay back your efforts shortly, or when there’s no other reasonable way out. Be less eager to restructure when there’s an unusually important deadline approaching, when you need to build trust with your client, when you’re uncertain about the benefits of restructuring, or when there’s another solution within the current structure that isn’t too unwieldy.

Focus on structural improvements

When your aim is to improve the internal structure of a system, such as introducing an InterestRate object instead of juggling doubles or integers, the graph is created with that improvement as the Mikado Goal. Everyone on the team should, in a coordinated way, build the graph and prune the leaves. Your focus should be on reaching the goal as quickly as possible.

This situation is rarely desirable from a non-technical point of view, because features aren’t continuously delivered and it’s hard to motivate further investment of time and money. Still, in the long run it may be crucial for the product. When the frequency of delivered functionality from developers to stakeholders drops, so does the level of trust, so you don’t want to get stuck in this situation. But in spite of this, it can be useful to make an investment that will make it easier to get future features out the door.

When you’re working with a system on a daily basis, you’ll get a general feel for how well the system responds to change. This knowledge is internalized, and you’ll consciously or unconsciously shy away from working on certain parts of the system. This is important information, because it probably affects both the spirit and productivity of the team. These parts of the system are good candidates to consider for a focused improvement effort.

In the loan server example, you might come to the decision that you’ll be adding more services shortly, and putting time into a focused effort to make that as easy as possible would make sense. The goal would be to “Create a pluggable architecture to easily add more services.” You would start by extracting the existing services, but you’d go on until all the services are extracted in the same pattern, with the same abstractions. All of those extracted services would be prerequisites for your goal. After finishing that restructuring, you’d be able to easily add new services, and you could return to normal feature development, adding the new services. Granted, some of the abstractions and the architecture might need to change slightly in the light of the new services you need to add, but the grunt work should be in place.

Combining structural improvements and implementing new features

Most of us are in situations where we need to make continuous structural improvements at the same time that we’re developing new features. The difficulty is striking a balance between the two. Sometimes there’s little or no need for structural improvement and everything seems to just flow. But as code becomes troublesome, there seems to be no end to the problems. At moments like that, you need to decide how to spread the work around. Should you do it over time or over people?

One way to find that balance is to split the team up and let some members work with new features, so the rest can focus solely on structural improvements. The Mikado Method lends itself very well to this sort of combined effort, because you’re always making small, nonbreaking changes in the leaves of the graph that you generally should be able to check in to the main branch. Another way is to spend a certain amount of time on features and the rest on structural improvements, but this approach has the drawback of increasing the amount of work in progress across the team, and it creates context switching that might be interruptive.

In order to maintain a healthy balance between structural and feature goals, you should set up for collaboration and communication to keep everyone aware of the shape of the system and what the rest of the team is doing. One way to achieve this is to update everyone regularly, perhaps with a daily sync meeting. This works well if the team is split between structural and feature goals. If the whole team is working on the same Mikado Graph at the same time, we recommend that a short recap be done whenever someone checks in something to the VCS.

It’s also possible for someone who’s working on a feature to signal everyone else that they’re about to touch code that’s possibly involved with the prerequisites in the Mikado Graph. By signal, we mean telling everyone in a room, if you’re co-located, that you’re going to change a particular piece of code. If you’re not co-located, an email or a Skype call might be more appropriate. This alerts the structure workers to pay close attention to that part of the graph, because the people working on the feature might change the prerequisites or close certain design possibilities. This signal is also a good opportunity to have a design discussion, and perhaps update the graph. There is, of course, a multitude of ways in which you can combine structural and feature work, and you’ll have to find out what works best in your context. If you pay attention to your development process and adapt regularly, you can normally find the conditions that work best for your specific setting.

Splitting the focus between feature and structural work is especially suitable when you have longer-term refactorings, or refactorings that are very complex by nature. It’s not unlikely that the system will need to be delivered several times before the improvements are done. One of the Mikado Method’s better features is that it enables you to do this work in the main branch, because the system is always in a deliverable state.

Picking the right focus

The following list summarizes the focus tactics you can use for different types of conditions:

· Structural improvements— You might want to focus on structural improvements when you have a technically neglected codebase or you need to make architectural changes.

· New features— You could focus on new features if fast delivery is crucial, or if you face low trust levels between the people responsible for delivery and the ones facing “business.”

· Combination— You might choose a combination approach if you have a large or highly mature team or if you need to work on long-running restructurings and new features in parallel.

4.2.3. Pain points when working as a team

The hardest parts of working as a team are communication and synchronization, and this is true when you employ the Mikado Method as well. Even though a Mikado Graph is very visual and contains details about a restructuring, it doesn’t replace the need to communicate actual implementation details and visions.

One common disagreement when it comes to implementation is the ambition level. At one point or another, someone will argue that the selected solution is too simplistic or that it barely solves the problem. If you ignore this concern, it’ll resurface sooner or later. We believe everyone needs to be on board and agree about technical decisions.

Another aspect of teamwork is who should own the graph, and we believe the whole team should. Just like we believe that collective code ownership is superior to having areas that each developer is individually responsible for, we believe that collective graph ownership is better than having all graph updates going through one person.

To simplify collective graph ownership, we recommend that the graph be shared between the whole team and kept in a highly visible space. That makes it easy for anyone to see what problems you’re currently facing and to dig in at any time. It also highlights the direction you’re trying to take the code, and when someone checks off a task, that can serve as a prompt for discussion if the implementation wasn’t obvious or should be discussed for some other reason.

When you work alone on a restructuring, you can do so either in isolation (using a refactoring branch), or you could do it in the trunk. Teamwork really makes you realize that restructurings should be done as close to the main delivery stream as possible. Synchronizing more version control branches makes all development more cumbersome, so try to avoid long-lived restructuring branches.

Having a homogeneous development environment simplifies your use of the Mikado Method, and it simplifies team-centric development overall. This is also true for homogeneous formatting of source code. If the code is structured slightly differently with inconsistent use of keywords or modifiers, merges will become a chore. Even things that seem like minor differences, such as the positioning of curly braces, spacing, and line breaks, can get in the way when you merge often. All formatting and code structure issues will become a lot more obvious because the rate of merges and how often you check in code will drastically increase. Frequent check-ins are, after all, one of the hallmarks of the Mikado Method. So before you plan a bigger restructuring in an area, we recommend that you format all code and check that in separately.

4.3. Summary

Small restructurings are possible without a detailed or carefully drawn graph. But as you get to medium- and large-sized restructurings, a well-kept graph is indispensable. A clue that you’re working on a medium-sized change is a feeling that the code you’re writing is a duplicate of already existing code—you may need to introduce an abstraction, or pull things out into a new module that can be used in several places. That feeling should prompt you to pull out a pen and paper, as restructurings like that can take a few days. If you realize, during your change effort, that every change is creating ripple effects throughout the system, or that your fixes are just opening up new cans of worms, you can be quite sure that you have a large-scale improvement ahead of you.

The Mikado Method can be used by a single developer, a pair, or a team. When you work as a team, you can start with features and handle restructurings as they appear, or you can have everyone working on restructurings. If the restructurings are significant, you’ll probably have to split the work so the team can work on both features and restructurings simultaneously, and the Mikado Method is well suited for that. When you’re learning the ins and outs of a system, you can start with small improvements, to clear away the “dirt” enough to see where the bigger structural improvements are needed. You can use the third-level tactic to grow into a larger change and see how the benefits of the method increase as the change becomes bigger and involves more classes.

This is the end of the first part of this book. You’ve learned how the Mikado Method works and in what situations it is best used. In the next part, we’ll look more at the technical side of working with the Mikado Method, and offer some guidelines on where to take a system, and how.

Try this

· How would you use the Mikado Method? In a team, as a pair, or as a single developer? Why?

· What do you need to get started? Make a list of your prerequisites.

· Make a list of the problems you see in your codebase. Mark them as small-, medium-, or large-scale problems. Where is the Mikado Method a good fit?