David Scott Bernstein's Blog, page 14

Pair Programming Pointers

Pair programming is the one Extreme Programming practice that I get the most pushback from both developers and managers.

Most of us have experience programming as a solitary art form and we’ve done it alone. We figured out a bunch of things for ourselves and we don’t necessarily feel comfortable doing our work in the presence of another. But think about how worse off medicine would be if surgeons didn’t pair up to do surgery.

If Uncle Bob Martin is correct and the number of software developers going into the field doubles every five years then we are an industry of amateurs with an average experience level of two-and-a-half years. Yet developing software is some of the most complex and intricate work that humans have ever engaged in. Pairing and mobbing are great ways to share information and refine skills as software developers.

So here are some basic tips for a successful pairing session.

Pair programming is not about taking turns at the computer. It’s about bringing two minds to bear on the same problem. It’s about collaborating and thinking through problems with another person to help us gain clarity. We do this all the time. I’m sure you have the experience like I have had where I was stuck on a problem so I called over a colleague and just thinking about how to explain the problem to them, I’ve come up with the answer. Externalizing a problem or saying it out loud to someone else helps us gain a different perspective and sometimes that’s enough to help us discover a solution that we hadn’t thought of before.

But pair programming is more than just externalizing your ideas. It’s about forming a true collaboration where both the driver and the navigator are engaged in solving the same problem together. These are typically not skills that we were taught in school or on the job, so learning how to effectively collaborate in a pair it’s something that we must be open to.

If we’re stuck and I suddenly get an idea that I want to try out then I passed the keyboard to my partner and have them drive. Likewise, if my partner has an idea and starts typing on their own then I’ll offer to be the driver.

I see the drivers role as primarily being in service to the navigator. As the driver, I try to handle the minutia of working at the keyboard so the navigator can think about things at a higher level of abstraction.

The navigator is also in service to the driver by giving instructions to the driver so that they are easy to understand and execute. The level of abstraction that a driver can assimilate is constantly in flux. If an operation is new to the driver then the navigator may have to spell out the steps in detail but once the driver is familiar with a set of operations then the navigator can give it a name and then refer to it just by name.

When we are pairing and mobbing I very often think that we are in service to each other. By working through problems together we gain different perspectives then we would’ve had by ourselves and we also learned a tremendous amount from each other. Much of the details of being a fine craftsman and software developer can be learned through pairing and mobbing. This includes everything from key bindings to coding conventions. Pairing and mobbing are the fastest ways I know to propagate knowledge across a team.

The Stigma Around Refactoring

Refactoring is a critically important concept in software. Anyone involved in the software industry should understand exactly what refactoring is and why it’s valuable.

Refactoring is not just the redesign of code. The redesign must behave exactly in the same way as it did before. In many situations, this also means bug-for-bug compatibility as well as expected behavior compatibility.

But refactoring is not just changing an implementation without changing its external behavior. Refactoring is also about doing it in small and safe increments. This is extremely important because we never want to be far away from a buildable system. Therefore, we go to great lengths to ensure that were taking baby steps in verifying what we’re doing by running our tests against the system after each baby step. This is important for leveraging feedback in making sure that we’re staying on track.

Whenever I have code that I can’t compile, I feel a bit vulnerable. For this reason, I try to implement my features in the smallest increments I can. There is a lot of value in taking baby steps. Today’s tools and machines are so good that we want to run them all the time and gain the benefit of constant feedback.

Ideally, other developers will have written good extensible code but that’s not always the case. When we encounter poorly written code we have the option of cleaning it up. Many of the automated refactoring options that are available in most IDEs are extremely safe to use, even with legacy code that doesn’t have good test coverage. You might be surprised at how much progress you can make in understanding and clarifying a legacy system with just the automated refactoring operations Rename, Extract Method, and Extract Class.

I know that there is a stigma around legacy code in many organizations because developers have tried to work with it, only to find that they introduced more bugs than they fixed. There is a lot of badly written code out there and there is also a lot of code that was written for one purpose and now it’s trying to be repurposed for something else. Before we add a new feature we often have to clear a space in the existing system for the new features. We do this by refactoring the existing system so that it can accommodate the new feature. This may involve adding abstractions or even introducing polymorphism.

When adding features to an existing system, I always recommend working in this way by first refactoring the code so it can easily accommodate the new feature and then adding the new feature.

If we have a set of good unit tests in place then when we’re refactoring the code we can do it safely because we know our tests have our back. If we write good behavioral tests and we refactor the behavior then our tests shouldn’t break. Instead, our tests are there to support us and catch any mistakes that we make. This is one of the places that the value of unit test for software development comes into play.

But even if we’re working on legacy code without unit tests we can still do many of the safe refactorings, especially if they’re automated in our IDE’s.

I think that refactoring is one of the key skills that developers need and will need in the future. Understanding how to safely go from one design to another design in code is amazingly freeing because it means that we can apply known and safe transformations to making our code more readable and understandable.

I want to help tear down the stigma around working with legacy code because most of the time the fear that we have is unfounded and unproductive. If we learn some simple techniques for refactoring legacy code safely then I think we can all sleep a lot better at night.

Read, Write, and Refactor

A couple of years ago I got to realize a lifelong dream when I became a published author. I was surprised to learn that many of the skills that I gained in becoming a good software developer were actually useful to me in becoming a good writer. Like code, prose should be well-encapsulated and cohesive, assertive and non-redundant, and all the other qualities that are virtuous in software apply equally well to prose.

I learned how to keep my writing and my speaking focused and engaging. I learned that when I deal with things on the same level of abstraction that it’s easier to understand and communicate. I learned that very often a central image or metaphor around an important concept really helps us understand at a much deeper level.

What I wasn’t expecting and turned out to be quite a pleasant surprise was that as I gained more skill as a writer, some of that knowledge could be transferred to writing good code. I want my code to be engaging and clear just like my writing. I find that even the basics of story structure can be used to help make the narrative of a piece of software more descriptive and interesting.

The stories that we use in Agile speaks of what, why and for whom a feature is being built. This is used to drive our acceptance criteria. At a lower level, we describe the behaviors that we want to create using a “given-when-then” format which says,

“Given some precondition, when a trigger happens, then some post-condition will occur.”

These statements can be translated directly into unit test code so they can be very useful. Our goal is to break down features into smaller steps that produce some measurable result so that we can write a test around it.

I’ve read many books on writing and still one of my very favorite books is Stephen King’s On Writing. One of the things that he says is that in order to be a good writer you have to do two things above all else. First, you have to read a lot of other people’s work because that’s how you expand your knowledge on how to turn a phrase and improve as a writer. Read from all genres and all styles. Read to study structure as well as execution.

The other piece of advice that Stephen King gives in his book On Writing is that in order to be a writer you also must write a lot. This is one characteristic that all great writers have in common—they spend a lot of their day writing. Not all of it is good, of course. But when the mood is right they are able to capture a lot because they’re butt was in the seat.

So, read a lot and write a lot. That’s the advice that Stephen King has for aspiring writers. For aspiring software developers, I would give some very similar advice with some caveats.

One thing the developers don’t do nearly as often as they should at all levels of experience is to read other people’s code. One of the big problems around this is that most people write really crappy code. Also, many developers may write good code but just simply choose to approach problems in a different way than we would. However, this is good because it teaches us different perspectives and ways of thinking.

Unfortunately, there are no libraries packed with best practices for coding in a variety of different environments. There is a lot of code out there if you know where to look for it. There are open source projects and tons of projects on GitHub and other repositories. But reading through this kind of code is not like reading the classics. Still, every once in a while I find some really interesting tidbits in code that make it worthwhile.

The second piece of advice, write a lot, I think is easier for most of us. As professional software developers, a good part of our job is writing code. The challenge is to continue to improve our skills as we continue to write code.

But there’s another aspect to software development that doesn’t have a strong correlation in literature but is very important for us developers to practice. We’re just beginning to realize the importance of refactoring code and how software is part of a lifecycle. We can use refactoring to safely and effectively transform even the most intractable legacy code into something better.

Knowing how to look at its design and discover patterns that we can easily refactor means that we can constantly improve the design of software and treat it like an asset that can be maintained and improved.

My Second Favorite Refactoring

In my last blog post, I shared with you my favorite refactoring and it might not have been what you were expecting. I just can’t leave the topic without sharing with you my second favorite refactoring, as well.

Like my favorite refactoring, my second favorite refactoring is also a safe refactoring, which means that if you have an automated refactoring tool that supports this refactoring then you can apply it to any legacy code, even when it’s not under test, although you might have to do a bit more work than renaming a method.

Also, this particular refactoring I feel is one of the most important for adding clarity to the domain model and making code much more understandable. Have I piqued your interest?

Well, my second favorite refactoring is Extract Method.

Extract Method is an automated refactoring that allows you to highlight a block of code and extracted into its own method. In the old days of programming when I was learning to become a developer 30 years ago, this was considered to be a poor practice. Back then, the reason that we created a method was so that we could call it from multiple places and eliminate redundancy. Having a method that you only call from one place seemed wasteful because it meant that you were making an indirect call rather than just putting that behavior inline.

My how times have changed. Today we see that inlining code is a poor practice because it can make control flow more difficult to see and it violates the Single Level of Abstraction Principle (SLAP) by having code call out both delegation and implementation details.

Today, I mostly extract methods, not because I intend to reuse them but rather because it gives me the opportunity to give bits of functionality a meaningful name. If you can name a behavior then it makes sense to wrap that behavior in a method with that name. This makes code expressive so it is more readable and understandable.

Wrapping a block of code in a private method with an intention revealing name is preferable to using a block comment around code. Instead of tracing through code we can start to get a sense of the different layers of abstraction that we’re dealing with and if our models are consistent and our entities cohesive then we can more easily identify defects based upon the responsibility where it occurs.

Long methods are the number one hiding place not only for smaller component methods but also for entire classes. When we fail to call out classes, we tend to distort our domain model, making it far more difficult to understand what we’re actually doing. As we start extracting out behaviors and identifying the entities that they belong to then we begin to refine our object model so that what we’re doing becomes clearer.

My Favorite Refactoring

Refactoring code is an essential activity when working with existing systems, as well as building new ones. Refactoring techniques allow us to safely transform code into designs that are perhaps better suited for future extension. The techniques used to refactor code range from very simple to quite complex and there is a strong emphasis to make small and safe changes to code so that we always have a buildable system.

Honestly, as I started to learn about refactoring and what it means I realized that the designs I come up with as I’m building a system don’t really matter because in practice it’s very straightforward to change the design as I’m building a system. After I’ve learned a series of techniques to help me do this, I found that is far more efficient to dive in and start building a system rather than trying to do a lot of upfront design.

What I’m doing upfront design I’m trying to visualize what the system will be like but I’m doing it in my head and on paper so is easy to fool myself. It’s also really difficult to see conceptually because we think in specifics, not conceptually. We think in terms of examples but we specify systems and talk about the design of systems as generalizations, so were constantly going back and forth between the general and the specific. Traditional specifications don’t give us a formal way of doing this whereas emergent design and test-first development does because we code from examples when doing test-first development.

The best time to visualize a system is when we’re building it out and I oftentimes do this through refactoring. Many IDE’s such as Eclipse and Visual Studio provide automated refactoring tools and this can save me a lot of time. Most of the basic refactoring operations have been automated and so they’re simple to use. There also mostly safe, which means that in many cases, we can use them on existing code even if that code is not under test.

My favorite refactoring is a safer factoring. It’s one of the things that I love about it. I can use this for refactoring on the most intractable and difficult to understand code without the fear of breaking anything. Plus, it’s my number one tool for understanding legacy code.

What is this amazing and magical refactoring? It’s Rename Method.

Having good, intention revealing names for methods is our first line of defense in documentation and helping readers understand what our code does. As I’m writing a method, I get clearer and clearer on what the method does and as I’m doing this I want to change the name of the method to reflect my new understanding. Rename Method lets me do this.

It’s a relatively simple refactoring with only eight steps, if you do it manually. I almost always use an automated refactoring tool to rename my methods so it’s simply a matter of highlight the method you want to rename, selecting the Refactor -> Rename menu option, type the new name and letting the tool do the rest.

I prefer long, intention revealing method names stated in the active voice. I don’t like abbreviations or acronyms. I like my names to be plain and simple. Methods should say what they do and that’s all.

I use the Rename Method refactoring more than perhaps any other refactoring and I’ll rename a method several times in the course of writing it as I get clearer and clearer on exactly what it does.

I also rename methods as I’m learning legacy code to give more clarity to the code. When I’m confronted with legacy code that I don’t understand then one of the ways I use to learn it is to rename methods if I feel their intention is unclear. Oftentimes, just the act of renaming key methods can help me gain a much better understanding of what’s going on in legacy code.

So, what’s in a name? Everything! Names let us give things meaning so make sure their meaning is clear, and if they aren’t use the Rename refactoring.

Surgery on Legacy Code

One of my early blog posts that I wrote nearly 10 years ago that I called Sony Baloney discussed how the electronics giant cultivated some unusual, yet highly successful practices. One of the practices that Sony is known for is taking young and inexperienced engineers and putting them on new product development, while their senior engineers focus on reworking and redesigning their successful products to be more cost-effective. I consider this to be a very wise practice and so do they.

We want innovation in new products but we always want to balance it so that our work is maintainable and cost-effective. The electronics industry pays a lot of attention to this because manufacturing is expensive. Of course, there are no manufacturing costs, per se, in the software industry but there are maintenance and ongoing costs for software and that’s actually where the bulk of our funds are spent. So, paying attention to the maintainability of our code is quite important yet often overlooked.

We don’t have many common standards and practices around developing software and so while software systems may be functional they are often very difficult to maintain. Most existing systems have accumulated a great deal of technical debt, which makes it difficult to work on, and in many organizations, there is a stigma around touching legacy code. This happens for good reason because when developers touch legacy code they often break it and that can be costly to an organization and embarrassing to the developer so our preferences to leave legacy code alone and when we have to go in to change or extend legacy code, we try to do it as minimally invasively as possible.

I realize that we mean well but this is often not the right choice. Surgery, if done improperly can cause great injury to the patient but that doesn’t mean that every time we do surgery to remove a tumor that we should only take a part of it. In software, providing just half a solution can be as fatal to a system as removing half of a tumor in a patient.

Surgeons have figured out how to do the impossible and open a person up so that they can remove a disease. I’m sure there are many important rules and caveats around doing this safely. I would never attempt to do surgery without first going through the process of becoming a doctor, no one should.

The same thing is true when doing “surgery” on an existing legacy system. We have to understand the root causes of problems in poor code and insufficient designs so that we can find safe and effective ways of remedying a situation.

Once we know some basic refactoring skills then it’s just a matter of applying them to improve the code. One of our main goals, when we refactor, is to make the design clear and straightforward. Doing this may include renaming methods and fields so that the intention of the extracted code is clear, and even extracting entire classes from methods if needed. As we do this, we call out missing components from our domain model, thus filling it in and making it more robust so it’s more understandable when we work with it in the future.

Sharing Knowledge

In my early days of computing back in the late 70s and early 80s, having an interest in microprocessor design was unusual. I remember getting almost monthly updates from Motorola and Intel on their latest chips and my shelves were filled with technical manuals.

Information flowed freely and it felt that we were part of a community figuring out how to use microcomputers in our daily work. There was a common feeling of camaraderie and it wasn’t uncommon to be able to pick up the phone and ask a technical question of a person who worked at a completely different company. We often posted what we learned on bulletin boards so others could benefit.

Then along came Microsoft. Software became a business and knowledge about how to do it became a valuable commodity. The industry started to close down and people were less ready to share information with those outside their company.

I’ve been at companies where people try to increase their value to the company by knowing more than other people and guard that information so that they retain that competitive advantage. This is really a post-industrialist perspective and it has no place in the Agile mindset.

In Agile, we encourage and reward exactly the opposite. We want people to share information and knowledge freely because we know that it not only helps them but it also helps all of us. We try to pair and work with as many different people as we can because we know that we have something to learn from everyone and through that process we improve as well.

Hoarding knowledge is not good for anyone. It puts your company at risk because you oftentimes become a critical resource for a particular tool or technology that only you can fix if it goes down and important things depend on it staying up. That’s also bad for you because it means that you can’t take a vacation or move on to other projects and so you may have job security but that can also make you stagnant.

In Agile, we want to be the guy or gal who helps others. We want to learn from them and we want them to learn from us. We really discourage specializations on a development team because we want it so that any developer can work on any part of the code. We also wanted so that all the code conforms to a uniform look and feel. This supports collective code ownership and allows people to read and understand a system more quickly and efficiently.

So, the best source of radiators are the people themselves because we’re always sending and receiving information. We want to work in an information-rich environment where we constantly know the status of our build and what we’re working on as well as what everyone else is working on.

As Rich Sheraton, author of Joy, Inc. says. we want to “filter out ambiguity” so people have a clear sense of the purpose of their work. This helps people get more meaning from their job and share knowledge more readily. Software development is a constantly changing field and so we want to be immersed in constant learning.

Encapsulate Change

Software development is a unique human activity but it bears resemblance to other activities such as math, writing, and engineering. I think of writing software as a modeling process but unlike modeling physical things that occur in space, we’re modeling processes that occur in time. Therefore, writing software is a process of creating models that are accurate and understandable.

It turns out that there are many ways we can model processes in software. We can model processes as a set of instructions or procedures. We can model them through a collection of objects that interact. We can even model a process as a series of transformations. Different processes call out a need for different representations.

The way we build software varies tremendously because we solve a whole variety of problems. This is why we have different programming languages and frameworks as well as platforms. There is no one-size-fits-all.

Software is used in almost every industry to solve a huge range of problems so it’s no wonder that the software industry itself has many facets to it. We specialize in languages and frameworks as well as different technologies but beyond that, we have to have some common thread that unites us, a common understanding about software development itself. I feel that all too often this is lacking in our industry. It seems like the goal is often just to do something that works and ship it without much regard to its supportability. The end result is that we’re cutting corners and we’re writing code that’s not as supportable as it could be. This drives up the cost of maintaining software and makes it difficult to extend.

One of the main benefits of object-oriented programming is that it allows us to build encapsulated, modular components that are independently testable and upgradable. However, rarely do I see developers use object-oriented languages to build software with these advantages. Instead of injecting dependencies as needed, they instantiate them inline and the result is that they can’t be tested independently.

In an object-oriented system, behaviors should be encapsulated in objects in order to limit side effects and allow the creation of a more modular system.

Code should be expressive, just like good literature. Code should express what it does and do its job plainly and clearly. Software should be expressed in the domain language and encapsulated in objects so that they’re more maintainable.

By spreading the knowledge of a system across a collection of interacting objects, we minimize the impact of change when it happens because change will typically only affect the objects that are directly involved in the change so the rest of the system will be encapsulated and shielded from the change. This is good because it minimizes the impact of adding new features to existing software.

Software lifecycle is important. We spend only 20% of our budget before release and 80% of our budget after the initial release of software. Less than a third of that is maintenance. The rest is fixing defects and providing enhancements. We are essentially building unmaintainable software in our industry and that is the norm.

Changeable software is not that much more difficult to create. It does take some more typing to put concepts into their own encapsulated entities but it also simplifies testing. Ideally, we would like to produce complex behaviors by applying a series of simple behaviors that we can independently test and verify.

Why XP After All These Years

I have been an advocate of Extreme Programming (XP) practices for well over a decade. To me, Agile software development means more than just an agile development process, it means that our code is agile and able to respond to change easily. This doesn’t happen by accident. It’s a result of following good programming principles and practices that support writing modular, maintainable, and changeable code.

It’s not enough to write software to make a computer do a specific task. The software that we write has to be agile. It has to be changeable without incurring a large amount of rework. It has to be safely extendable so that we’re not putting our systems and our users at risk as we add new features.

Many people even within the industry are unaware that we have solutions to most of these problems. We have well-defined methodologies that allow us to transform existing code into designs that allow us to accommodate new features and we are able to do these things in a safe and repeatable way. In other words, software engineering can be just like any other form of engineering in terms of having standards and practices that support us.

I found that many of the practices from Extreme Programming as well as the concepts from the design patterns movement, object-oriented programming and functional programming movements, software craftsmanship movements, as well as Scrum, Kanban, and Lean Software Development movements. All of these approaches are about addressing different aspects of software development and together they often form whole solutions to previously intractable problems.

Our industry has come a very long way in terms of being able to build reliable systems cost-effectively but the problem is that these ideas are not common knowledge throughout the industry and so the benefits of these practices that are used by some of the top corporations in the world haven’t really trickled down into the rest of the community of software development.

The whole discipline of software development is rapidly evolving and so it’s important not to just keep up with the latest tools and technologies but also to keep an understanding of the fundamentals fresh and top of mind so that we understand the reasoning behind the core practices and how to do things in standardized ways so that they’re straightforward to integrate with other people’s code.

We’re trying to build a discipline, after all. That means that the tools and techniques that we build have to work for all of us and we have to arrive at some level of consensus and agreement for what the standards and practices should be for developing software.

I think Extreme Programming offers a core set of developer disciplines that are highly valuable. I think our industry would be far better off if we paired more often and place more of an emphasis on refactoring code safely and writing good unit tests. I think these things raise the level of professionalism in our industry.

When I think about a minimum set of developer practices that really support an iterative process of software development that we do with Agile then it’s clear that the practices of Extreme Programming are essential when doing Scrum.

I find test-driven development to be invaluable for writing testable code that allows me to refactor my design safely. I find that refactoring is extremely valuable for allowing me to transform code from one design to another, which often is required when adding new features to a system. This is the kind of knowledge that makes us professionals and lets us build software in a consistent way.

So, many of the ideas that are embodied in Extreme Programming are some of the most valuable ideas in software development that I’ve ever come across. Even over a decade and a half later I still find that many of the ideas from Extreme Programming represent the best approaches that I found for object-oriented development.

Scrum and XP

I’ve been fortunate enough to speak at several conferences on Agile developer practices. I presented at many Scrum Gatherings both in the United States and in Europe. I’ve also presented at several of the big Agile conferences as well as the smaller technical conferences such as deliver:Agile and most recently Craft Con in Budapest.

Most of the time at these conferences, I ask the audience two questions and I’m always surprised by the answers I get. I ask how many people are doing Scrum and most of the audience raises their hands. Then I ask how many teams are doing the Extreme Programming (XP) practices and nearly all the hands go down. I usually see far less than 1% of the audience who says that they’re doing Extreme Programming. Some people looked puzzled and even asked me what Extreme Programming is.

Then I read them the last two sentences of the book description Software Development with Scrum by Ken Schwaber and Mike Beadle.

“This book shows readers how to use SCRUM, and agile software development process, to quickly and seamlessly implement XP in their shops while still producing actual software. Using SCRUM in the agile process can virtually eliminate all downtime during an XP implementation.”

So, Scrum was created to help you be more effective when doing XP and today everyone is doing Scrum and virtually no one has heard of Extreme Programming.

The original authors of the Agile Manifesto who met all those years ago in Snowbird, Utah are all software developers. Agile was created for software developers by software developers and Agile software development has always had something to do with software development.

It’s time we recognize the value of these technical practices because that’s where we get all the real benefits of Agile software development. If you apply old and outdated development techniques and you built in sprints you’re still going to end up with a poor codebase. Agility requires a focus on good technical practices and in my experience these practices are not commonly known in our industry. They’re not being taught in schools and a lot of people haven’t learned these practices well on the job.

The practices of Extreme Programming such as refactoring or test-driven development aren’t simple and aren’t easy at first but technical agility is predicated on technical excellence and if we don’t have well-written code and good automated tests then software will be very difficult to change and no matter how many processes you put in place, you’ll find that it will be very difficult for your developers to get any work done.

So, I’m an advocate of Scrum and I’m also an advocate of Extreme Programming. I’m actually quite surprised that a series of ideas and practices that have been around for nearly 2 decades is still so valuable but the creators of XP really nailed it and I think they’ve come up with a really valuable set of practices that can both accelerate quality and quantity of software being created.

The first principle of the Agile Manifesto says so much. It says, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” In order to have continuous delivery of valuable software, we have to automate as much of the software development and the verification process as we can.

I think they were just starting to recognize that test-first development and code refactoring gives us safe and reliable ways of cleaning up existing code and therefore improving its affordability and its extensibility.

This is what the software engineering discipline is all about and like any other engineering discipline, it must have standards and practices. Most developers that I meet don’t have standardized ways of going into legacy code and cleaning it up. Understanding how to do these things safely is very important for software developers to know.

It’s not uncommon for innovative new ideas to take root in unusual ways. I’m happy that Scrum is so popular and what I want to say is don’t stop there. Scrum is the first step, so use it to help you get more out of Extreme Programming practices, the way it was intended to be used. Set up continuous integration and figure out how to build good unit tests to automatically validate your code.

Legacy code can look overwhelming but we got there one step at a time and that’s the very way to get out of it, one step at a time. Little wins add up and with a concerted effort, even the nastiest codebase can be tamed.