Book Review: Working Effectively with Legacy Code

I just finished reading Working Effectively with Legacy Code by Michael C. Feathers (Amazon link).  I'll dispense with the standard review since this book has been around since 2005 and has many reviews and recommendations.

The short recommendation: Read this book.  Even if you aren't working with existing code that needs to be updated, the techniques can be used to recognize potential issues on new code that you're writing.  And if you are trying to untangle an existing code base, this book is invaluable.

Refactoring for Testability
The best way to describe this book is "refactoring for testability".  The idea behind this is that if you need to make modifications to code, you need to first have tests in place.  If you do not have tests for the existing code, then if your changes break the current functionality, you won't know about it.  With tests in place, you will know if you break something as soon as you make those changes.

This is a "Do no harm" approach.  The code that you are walking up to is working code (you're adding features, not necessarily fixing bugs).  The last thing you want to do is to remove the "working" part.

This is especially critical if you are working with code that you didn't write yourself (or even code you did write yourself several years ago).  You need to recognize that if you are going to be successful in working with unfamiliar code, you need to make small changes one step at a time.

Three Parts
The book is broken down into 3 parts.

Part I: The Mechanics of Change
Part one focuses on why we need to make changes to code, how unit testing can help us make confident changes, and several tools and techniques (such as finding/creating "seams", refactoring tools, and mocking). This is a high-level overview of why we need to start working this way (refactoring for testability).

Part II: Changing Software
Part two focuses on specific problems that you may encounter in the code -- things that make the code hard to get into a test harness.  Personally, I just like reading the chapter titles.  Here are a few:

• I Don't Have Much Time and I Have to Change It
• I Need to Make a Change, but I Don't Know What Tests to Write
• Dependencies on Libraries Are Killing Me
• I Don't Understand the Code Well Enough to Change It
• My Application Has No Structure
• My Test Code Is in the Way
• My Project Is Not Object Oriented. How Do I Make Safe Changes?
• This Class Is Too Big and I Don't Want It to Get Any Bigger
• I Need to Change a Monster Method and I Can't Write Tests for It
• How Do I Know That I'm Not Breaking Anything?

Part III: Dependency-Breaking Techniques
Part three consists of a catalog of 24 techniques that you can use to bring code under test.  These are all presented in a short (usually 3-5 page) format with an example and specific steps to follow.  These techniques are referenced in Part II, so you'll probably be familiar with the concepts.

Some examples:

• Break Out Method Object
• Encapsulate Global References
• Expose Static Method
• Extract Implementer
• Extract Interface
• Parameterize Constructor
• Pull Up Feature
• Push Down Dependency
• Subclass and Override Method

This seems kind of "design-patterny" in the sense of having a catalog of well-named techniques.  These techniques aren't perfect.  Michael Feathers notes in several places that some of these techniques actually make your code "worse" structurally.  But they are still valuable because they increase the testability.  The theory is that the more you work with the code, these bad structural patterns will be refactored into more organized code.  But the point is that these changes are all made incrementally -- one, small change at a time.

An Example
One chapter that especially jumped out at me (not sure why -- probably because I've seen this before) is "I'm Changing the Same Code All Over the Place."  This has to do with reducing the duplication of code between 2 classes.

What I really liked about this chapter is that it shows the reduction in duplication is small steps.  There is no, "just extract everything to a superclass and you'll be fine."  Instead, it starts by figuring out what the commonalities are between the classes -- starting with properties and methods.

The first step was to create a superclass with *one* common method.  Then the implementation methods (in each class) are updated to make them more similar (by extracting out a method to make the body of the common method identical).  Then this implementation can be moved up to the superclass with only the differences (the extracted method) in each subclass.

The next step was to move the common properties up to the superclass.  Then the refactoring continues one step at a time.  When we are left with some unique properties in each class, the question is can we combine these into a common collection.

I don't expect that this description will make much sense out of context.  The point is that instead of thinking about the refactoring in big chunks, we are thinking about it in very small steps.  At each step, we can make sure that the tests still work as expected.  And if a test fails, we can immediately know what happened.  If we were to do a "big blast" change and the tests fail, we won't know specifically what the problem is.

As someone who has rolled back big chunks of changes (because it didn't work and I wasn't quite sure why), I really appreciate this approach.

Wrap Up
To wrap things up, whether you need to modify an existing code base or you are just looking at techniques to make your code more testable, Working Effectively with Legacy Code is an excellent read.  Note: none of the examples are in C#, but they are in C-family languages (C, C++, and Java), but C# is mentioned in many of the techniques.  (There's also one Ruby example for a technique that deals with dynamic languages.)  If you are comfortable reading C#, you should be able to understand the examples just fine.

I'm always looking to improve my coding techniques, and I'm sure that I will be thumbing through this book many times in the coming years.

Happy Coding!

Development and the Business - A Partnership

A couple of months ago, I posted some thoughts on The Clean Coder.  Part of this included how developers should be in a partnership with the business area.

This was reinforced in a recent episode of .NET Rocks! (Is Agile Dead at CodeMash).  A panel member (sorry, I don't remember which one) polled the audience.  First, he asked how many people were part of the "business".  Result: one or two people.  Then, he asked how many people were part of "I.T."  The result was most of the audience.  He immediately said that this was wrong -- that everyone is part of the business.  That's why we (as developers) exist.

As another example, we can look at the Principles behind the Agile Manifesto. Specifically, "Business people and developers must work together daily throughout the project."

Forming a Partnership
So, how do we go about forming this partnership?  Previously, I mentioned that I really didn't know.  But it turns out, I did.  I just needed to look at my experiences in a bit of a different way.  I mentioned how I have worked in an environment where the development teams and business areas had very good relationships.  But even if we don't have this particular environment, we can work towards it.

Note: I'm approaching this from the standpoint of a corporate developer -- a developer who is building applications to help the company get work done.  You will need to modify these ideas just a bit if you work for a software company or build products for people who don't work for your company.

Watch: Learn How the Business Works Today
The first step is to see how your users do their day-to-day work.  Start by spending a day with one of your users.  Watch everything that he or she does.  Your job at this stage is to simply see how the folks in the business area get their job done.

Keep your mouth shut.  Think of yourself as a wildlife photographer -- you record what takes place in front of you, but you're not allowed to intervene.  If you see someone fumbling with a process or a piece of software, make a note of it, but let him fumble.  You're not there to give advice; you are there to see how things are done.

Take notes, but don't immediately start thinking about how you would change things.  As developers and problem solvers, we have a tendency to let our brains run wild.  But this distraction can keep us from making some important observations.  So, just keep watching.

Listen: Learn How the Business Wants to Work
The next step is to talk to your users.  Ask them what they think would make their jobs easier.  Find out how they want to work.  This is still part of the observation stage.  Don't immediately start trying to solve problems; just keep collecting information.  The key is to listen to how they would change things.  Periodically review your notes with the people you are talking to.  This will ensure that you are collecting the correct information and has the added bonus of giving the users confidence that you are really there to listen and help.

If you're dealing with front-line workers, also talk with their management team.  Ask the managers what they think works well and what doesn't work well.  You may find out that the management team would like the front-line workers to focus on different priorities -- maybe there are short-term goals that change from time to time.  If you can, try to sit in on one of their team meetings.  This will give you better feel for what is important to them.

As before, don't let your brain start problem solving.  You're still collecting information.

Analyze: Review What You Learned
After you've collected your information, it's time to start analyzing.  Now is time to let your brain run wild.  Think about the software that is being used (or not used).  Review the stumbling blocks the users may have had (for example, did they have trouble finding a particular function?).  Think about the processes that were not automated that could be.  Maybe you noticed that someone took data from an email attachment and re-keyed it into a different system.

At this stage, don't be afraid to follow up with anyone that you've talked to out in the business area.  Often, after you start analysis, you find out that you don't have all of the information that you need.  You can use some quick follow-up questions to fill in the gaps.

Contribute: Take Your Plan to the Business
Now that you've had a chance to come up with some suggestions, it's time to take them to the business.  Start by grouping your solutions into "quick wins", short-term, and long-term time frames.  Once you have this, go back to talk to the folks in the business area.

Hopefully you have a couple of "quick wins" to start with.  These are items that would be easy to implement from a technological standpoint (with minimal cost and resources) and would add good value to the business area.  This is where you start to build trust.  The quick wins show that you understand the business and that you are able to help.

If you "missed" on the quick wins, don't get discouraged.  If the business area did not like your ideas, it's your chance to gather some more information.  Ask some clarification questions and listen.  Figure out what you misunderstood and work toward correcting that.

If the "quick wins" are a hit, then give brief descriptions of your short-term and long-term solutions.  This is an opportunity to plant some ideas for future projects.

Continue: Constant Interaction
Congratulations, if you've gotten this far, then you are well on your way toward a good partnership.  Now you need to make sure that you continue this relationship.  If you start implementing some of the solutions, stay in constant contact with the business area throughout the process.  Give them prototypes and get feedback as you go.  Back to the principle we mentioned earlier: "Business people and developers must work together daily throughout the process".

Benefits of a Partnership
Ultimately, the business benefits from this relationship.  As a developer, you are more in tune with how the folks in the business area think.  Your software will naturally head in the direction that the business needs.  In addition, the folks in the business area will trust your judgment.  Once they see that you are all working toward the same goal (the improvement of the business), then they are more likely to accept your suggestions.

A partnership is about building on the strengths of both members.  The business area has operational experience -- they know what work needs to be done.  The development area has technical experience -- they know how to automate processes and build working software solutions.  Working together, the entire business benefits.

Getting Buy-In
One of the issues you may face is getting buy-in from your management team.  It may sound like you will be spending a lot of time "not developing" as you are doing "partnership" work.  But this really isn't the case.  Plan on spending one day a month in the field -- this really isn't all that much.  The rest of the time is touching base from a few minutes to an hour at a time.  You might spend a bit more time getting things started, but it will just become a natural part of your work after that.

"Agile" is a very popular term to use.  Many development teams claim to be Agile, but often they are only using a couple of buzzwords and work in "sprints".  But ultimately, Agile is about getting working (and useful) software into the hands of your users as efficiently as possible.  If you don't understand how the business works, then this becomes very difficult.  (Note: this is part of the discussion of "Is Agile Dead" from the .NET Rocks! episode mentioned above.)

Wrap Up
I have been fortunate enough to work in a very productive environment where I was able to form strong partnerships with my users.  In that position, my management team understood the importance of these relationships.  I was able to respond quickly to my users' requests (since I understood what direction they were headed), and I was also able to make relevant suggestions to improve the process.

Just remember:

• Watch
• Listen
• Analyze
• Contribute
• Continue

It's important to remember that we are all working toward the same goal: the success of the business.  The better that we understand it, the better we will be able to contribute.  And, ultimately, we will all succeed together.

Happy Coding!

February Speaking Engagements

I'll be speaking at a couple of user groups in February.  If you're in the area, be sure to stop by.

Tuesday, February 5, 2013
San Diego .NET Developers Group
http://www.meetup.com/San-Diego-NET-Developers-Group/events/102264182/
Del Mar, CA

Topic: Dependency Injection: A Practical Introduction
The focus is getting a good handle on why we might want to use dependency injection in our code, what it can do for us, and the tools that we can use to make it easier to use.

Thursday, February 28, 2013
dotNet Group.org
http://www.dotnetgroup.org/
Las Vegas, NV

Topic: Get Func<>-y: Delegates in .NET
In Las Vegas, we will get a bit "Func<>-y" (and a little "Action<>-y" -- yeah, I know, it doesn't quite work the same, does it).  We'll be taking a look at delegates and how we can use them to add extensibility points to our code while adhering to the S.O.L.I.D. principles (specifically the "S" and "O" parts).  We'll also see how the built-in delegates Func<T> and Action<T> add flexibility and make things more readable.

Hope to see you there (or another event coming up this year).

Happy Coding!