Skip to content
Home » Blogs » pbielicki's blog

Refactoring in action

July 24, 2008 by Przemysław Bielicki

Quite recently I attended my company's internal presentation regarding agile software development (ASD). During Q&A (questions and answers) part someone who was not convinced to use ASD complained that refactoring means rewriting the code from scratch. It's bullshit, of course, but as you can see people who don't know ASD can proliferate misconceptions about many ASD ideas.

In this post I would like to show you an example of refactoring in an unconventional way. I hope you will like it.

My very first apartment
Two years ago I bought my very fist apartment in the center of Gdynia. This picture of the kitchen was taken a day after housewarming party (before the rennovation):

Refactoring phase
We (me and my wife) didn't want to change too many things in this flat. We wanted to have a new kitchen and bathroom but the rest should be more or less untouched. In other words we wanted to do only slight refactoring of our apartment.

We were Product Owners and we changed our mind after some pieces of advice made by our parents and friends and we decided to change electrical, heating and water infrastructures as well. The refactoring was getting more serious.

When the heating and electrical teams finished they work (they completely destroyed our bathroom - this was part of the plan, unfortunately) we employed another team in charge of making our bathroom and walls flat ;) shiny, colorful and beautiful. At that stage we really wanted to keep the parquet on the floor but as our refactoring proceeded we discovered many unpleasant surprises ;) We had to remove the parquet and fill some holes in our floor with new layer of concrete! Oooops!

Our "product" looked like this (the middle of the "release"):

Refactoring often hurts
I as a Product Owner was in despair - I didn't want to watch this mess. Our apartment looked like big shit and it was getting worse and worse. Our refactoring phase was at the peek!

I was a good project manager of this project and coordinated work of 5 different teams - when one team finished the job the next one entered the flat few days later. Of course we had many many problems with the guys and it was often big hurt but my stubbornness and will made it to the happy end.

The refactoring was painful (especially that it was our beloved and very first apartment we wanted to inhabit very quickly) but the effect was stunning:

Retrospection
Our release took 2 months and the phases we went through were:

  1. completely destroyed bathroom
  2. destroyed walls in every single room
  3. destroyed floors

and maybe something more traumatic but I don't want to remember this.

We didn't destroy the structure of the walls and any other fixed elements of the building but within the flat we refactored almost everything. We made this flat amazingly beautiful, safe and modern (all "middleware" infrastructures are new). And it was worth it - even taking into account "renovation trauma" we still have :)

Software analogy
Please note that the analogy to the software refactoring is not very strong here as you will be probably tempted to perform rather shorter refactoring cycles. However, such big software refactoring happens (I used to do some) and can last even for half of the 30-day iteration but you have to perform them very carefully (hopefully you have good test coverage and you can sleep well after such operation). Going with this analogy further - it's much easier to make another short software refactoring task after few iterations and add some more features than destroying another room in the apartment while already living there - these worlds are not 100% compatible here :)

Refactor or not?
I think this example is quite extreme but hopefully shows how code refactoring could look like. In the middle of the refactoring phase, which can be project-wide and affect 80% of your classes and packages, you can have complete mess (or brothel if it translates to English). But at the end refactoring pays off and you can easily get new infrastructure and internal design. Your code will be more extensible and ready to implement new features. And it's not rewriting your code from scratch (look, we didn't destroy the whole floor of flats - we reordered the internals).

If you need to refactor your code significantly and you know the value will be greater than the cost you should definitely go for it. It could be painful, your manager and colleagues could hate you during this period of time but when they see the effect they will love you (of course if you succeed :). And you could go on holiday - someone else will add new feature basing on new refactored code.

Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Propeller
  • Reddit
  • Technorati

About the Author: Przemysław graduated from Gdańsk University of Technology in 2004 having specialized in Distributed Information Systems. He worked in Lufthansa Systems, Intel Corporation in the past where he developed complex IT solutions in many Java-related technologies. In professional life he is a real Java expert holding couple of Sun Java certificates (Programmer, Developer, Web Developer) and Certified Scrum Master, of course.

Przemysław is a regular contributor to AgileSoftwareDevelopment.com and the author of "From Java to Java EE" blog. He now works as a Software Craftsman in an international company that is the leading Global Distribution System (GDS) and the biggest processor of travel bookings in the world. Contact Przemysław

Permalink

Comments

this is a poor refactoring analogy

July 24, 2008 by Coleman (not verified), 3 years 28 weeks ago
Comment id: 1707

This is NOT refactoring, this is rewriting. Refactoring would have been replacing the cabinets, then replacing the flooring, then rewiring, then painting, etc. Refactoring is defined as improving the design of existing code while keeping or adding to the same API. Refactoring is not supposed to be painful; it's supposed to happen in short chunks with great confidence since you have more than adequate test coverage.

I have just completed a refactoring of several classes which were simply not designed well. The API was solid, however, and I did not have to change ANY of the API. Some class names changed but that was a simple matter of compiling and fixing the few constructors that were now incorrect. This took a day and a half and I made quite certain that other developers were not affected; where they would have been affected I cleaned up my own mess. I have a feeling your wife would not consider your "refactoring" to have been quite as successful. ;)

A few more observations: you MUST remember the traumatic parts of the sprint during the retrospective or your retrospective is not worth the time you put into it. If you are budget sensitive, you cannot afford to take half a 30-day iteration to refactor. You have to work within the budget; if changes to the app require refactoring, however, this should be added to the budget. You just can't refactor because you think it's a good idea, there MUST be a business case for it.

Actually it is, and all too typical of legacy code

July 24, 2008 by peterstev, 3 years 28 weeks ago
Comment id: 1712

As I understand refactoring, it means modifying the architecture to meet new requirements. The customer wanted a nicer place to live. Replacing the building was not a viable option (constrained by costs and other residents or stakeholders), so the building had to modified to meet the new requirements.

Sounds like a refactoring to me.

The "code" was pretty old, nobody really understood it. Initially they had hoped that repainting would be enough, but as they learned more, they had work on more deeply buried problems.

The building is still there. Floors and ceilings and window are still the same place. He didn't replace any structural supports or change the number floors, so we still have the original building. But the apartment is much nicer now, and safer too, with new electrical wiring and other improvements.

So in my book this was a refactoring. Quite a painful one, I admit. If he owned the whole building, he probably would have thought seriously about tearing it down and starting from scratch. But that wasn't an option. (And if I owned the building, I might consider investing more in maintenance). But it represents fairly the problem you have with legacy code.

The hard part in refactoring is ensuring that nothing breaks, i.e. that all dependencies still work properly. That is where automated testing and continuous integration play a critical role. I wonder how to apply the remodeling analogy to that part of the problem.

Cheers,

Peter

I wrote what you mentioned

July 24, 2008 by pbielicki, 3 years 28 weeks ago
Comment id: 1713

I wrote what you mentioned in the "Software analogy" part.

It seems that you've never renovated any flat or apartment. Basically it looks like you wrote replacing the cabinets, then replacing the flooring, then rewiring, then painting, etc. one after another but you cannot call it done until the last operation. And it's time consuming.

I love agile methods because they force people to THINK and not to stick to some stupid rules. Of course most of the time refactoring would mean short cycle and blah blah blah what you wrote. But sometimes you work with so shitty code or you postponed previous refactorings until the shit hit the fan that you have to do BIG thing at once. So what? Should I tell my Scrum Master that I cannot do this because it will take more time than "short"? You have to think and if the only solution is to do the painful refactoring - DO IT.
I've performed hundreds of refactorings and most of them were short. Some of them were big and painful and they still were refactoring - I didn't add any single line of code (maybe except creating new empty classes and moving existing methods from other classes there). And everyone knew it's going to be painful but we all still agreed to do this. We delivered everything we wanted during the Sprint - did we do something wrong? No.

And about the apartment, well, I wish you as many successes with your apartment as I had :)

PS. BTW. I agree with you that refactoring should be short and not painful but well, sometimes you have no choice.

If you can still go to the

July 24, 2008 by Coleman (not verified), 3 years 28 weeks ago
Comment id: 1716

If you can still go to the bathroom, and still turn on the lights, and still cook dinner, that's refactoring. I stand by this being a rewrite. The design was improved, sure, but at the cost of weeks (maybe months) of downtime. I actually have renovated a kitchen. First we replaced the flooring. A couple of years later we replaced the cabinets and immediately put back the old sink/countertop (cabinet installers around here don't generally do countertops too) so we would keep eating at home for the next month. The backsplash was beat all to hell but the walls were still there. The new counter and sink were installed the same day, then the tile backsplash weeks later. We had a total of one night where we couldn't cook (but many when we didn't want to!). That's refactoring a kitchen.

Not saying all your code rewrites were the wrong thing to do, they just aren't "refactoring." That word is misused ALL the time, even by people in my organization, and I correct them every single time. Refactoring was defined by Martin Fowler as improving the design of existing code. It's made faster, more elegant, more efficient, more readable, more maintainable. It's NOT thrown out and redone from the ground up, and at no point during a refactoring should the code be in an unusable state. If you're not refactoring all the time, you're not using agile practices. At no point in a well-managed agile project should you reach the point where you go "oh crap this is gonna hurt."

Anyway, the point was this is a thin analogy and is really more analogous to a rewrite. Obviously you didn't tear the building down and start over; that would be more like ditching the platform altogether!

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of AgileSoftwareDevelopment.com