This site uses 3rd-party cookies for targeted advertising. If you do not agree to this, then please leave this site now. Otherwise please click on "Ok" to continue.
Ok
 
 

I Am Proposing "Refactor Fridays"

09-Jan-2015

We all know that we should frequently refactor our code, so that it stays in good shape despite all the things we changed or added.

So let's show up hands who of us actually does this? Oh... only a few out of all the people here? Just what I thought... :)

Hmm... how can we actually get this done, then?

I am now proposing "Refactor Fridays"

I think it would be best to set aside some fixed timeslot to do your refactoring. Do nothing else during that time, only refactoring, cleaning-up your code.

If you keep this as a fixed routine, it will help you not to procrastinate. Because if you have to decide whether to do it now or later, you are likely to do it later, or much later, or not at all. That's why you should keep this as a fixed item on your schedule.

Why Fridays? Well, most of us are already in a yay-it's-almost-weekend mood. You are already mentally winding down, so it'll give you a relaxed moment to look back at the code you wrote that week, identifying spots where it needs to be refactored, and then doing that.

It also means you get to take another look at all the things you've achieved that week. You will end the week by leaving your code in a state that you can be proud of. Which will give you a really good feeling.

And on Monday you'll get to start a new week of working on your code, knowing that it is in good shape and not in dire need of some cleaning-up.

Comments:

Author: (Unknown)
2015-01-11 17:49 UTC
 

This also helps to prevent the Managerial tendency to dismiss refactoring as unneeded

Author: (Unknown)
2015-01-12 12:13 UTC
 

It may help preventing going towards entropy

Author: (Unknown)
2015-01-15 10:22 UTC
 

Nice in theory but reality is, refactoring is hardly ever a 1 day job so you don't "start the new week in good shape" you "start the week with your repo in an unusable state and spend Mon-Wed continuing the clean up" :)

Author: (Unknown)
2015-01-15 10:56 UTC
 

Good idea! I can already see myself saying 'Bah, anyway, I will just refactor this on friday...'

Author: (Unknown)
2015-01-16 21:00 UTC
 

I like it. Just like "Release early, release often", build the refactor time in from the start should keep those efforts manageable within the 1-day allotment.

Author: (Unknown)
2015-01-19 16:15 UTC
 

We have the practice of letting one developer per day work on software quality. This can be refactoring, or rethinking processes, or writing more and/or better tests for critical parts, and so on. This way we get to do at least one day per week on refactoring.

Author: (Unknown)
2015-01-19 19:25 UTC
 

I like that you're promoting reduction of technical debt, but I'm not sure that promoting a day on which you do it is the solution.

There's only one approach to refactoring that I've ever known that works, and that's to do it at the time that you touch the code that needs refactoring. It should be part and parcel of shipping features.

There should be no debate without managers about whether this is a good idea; as a technical person, and manager of yourself (at the very least), your opinion is the one that matters.

In order to make the right decision for the business, don't ask yourself "can this code be cleaner?". Ask "if I were to clean this up a bit, would the company make more (or save more) money?" The timescale over which they migh make/save is also worth considering — short term wins can sometimes make sense — though I generally find that tidying up as I go is by far the cheapest approach. Don't leave it until Friday, or encourage others to do likewise.

Doing it on Fridays has another risk; you might spend more money refactoring than than will be redeemed by doing it. In other words, you might improve code that you'll not use that much in future, which limits your savings.

My advice: refactor code when you find yourself using it, and can see an opportunity to make it cheaper to maintain. Make that part of your process, and your code will improve, your costs will go down, and your life will become more fun.

As always, mileage of this advice varies with the context in which you apply it (there are no absolutes). I'm just saying we can aim higher than doing it on Friday.

Graham (graham@effectif.com)

Author: (Unknown)
2015-01-22 03:21 UTC
 

Chad Fowler introduced this practice at LivingSocial in 2012. It worked quite well. Some tech debt items carried over for a few weeks. As a team leader, I also made sure team members had Mon-Thurs time to concentrate on big refactorings that merited it, and we practiced the boy scout rule.

We do this at LearnZillion now with good success. It's not a silver bullet, but it does a lot to pay down debt.

Ian Lotinsky VP of Engineering LearnZillion

Author: (Unknown)
2015-01-23 20:45 UTC
 

Doing any major code changes on a Friday is a good way to introduce problems into the codebase as:
• very few refactors worth doing take just one day to execute and test
• most people aren't their best toward the end of the work week
• most of the refactors won't be tested before submitting
• the gap in time from Friday to Monday is enough to "lose" some of the momentum you had

Within my team it's usually a step we try to leave time for before heading into QA in order to keep the debt down and also allow for more testing at the Developer level before the whole of the team gets a crack at it. We also try (and have had some success) in introducing this into sprints of their own on larger projects with long timelines. Especially for Apps that are updated/upgraded over time.

You want to comment on this blog-post? If yes, then simply enter your comment in the field below and click on "Submit".

Comments are moderated at the moment thanks to some $%&# who thought it would be funny to post total nonsense here.

 


Back to the Homepage

A Programmer's Diary