How much time do you spend on research / refactoring?

Question

Staying up-to-date is essential in the programming world as new technologies / methods etc.. are so quick to arrive (and depart). So how much time do you spend doing this? Does your employer allow you to do this on their time? Or do they expect that as a professional it is up to you to keep your skills up?

On a related subject, how much time do you spend refactoring your code? Do you find yourself having to push projects through the door using the same tired old codebase or do you make sure you have the time to maintain and update it accordingly? How easy do you find it to convince your employer that spanding x time refactoring will save twice that in maintainence time down the road?

Answer 1

This article by Steve Rowe is often cited as an answer to this sort of question. His advice is excellent on this topic:

Here are some rules of thumb for deciding when to refactor:

• Even if code is ugly, if you don't have to change it, don't fix it. You just risk breaking things.
• If you are adding some functionality and it is hard to implement, refactor.
• If you have to change the same code a second time, assume you'll probably be back a 3rd and 4th time and refactor.
• If you don't have unit tests, think long and hard before refactoring. Without tests, you can't know you didn't break anything. Write unit tests first if necessary.

Answer 2

My employer gives us enough time to study. We have monthly meetings to share knowledge. And we can go to conferences and courses if we need it.

Most of the refactoring is done during normal maintenance. I can't say for sure how much time I spend on it. Sometimes the whole day, some weeks nothing.

Answer 3

I would say I spend between 10 and 20 hours a week researching (at work and at home). My employer doesn't have an opinion one way or another if I do it, as long as my work is done.

I refactor my code as I go along. If there is something that needs to be corrected in a module I am working on, I will try and change it as long as doesn't have a wide spread affect on the rest of the system. Those I make sure get scheduled time in a release, so we can properly take the time to refactor and test the changes. How do I convince my employer? I tell management it needs to be done. I explain what needs changed and the benefits to making it. Sometimes I lose the battle and we postpone doing it until later, but generally making the code better has their best interests at heart, as it will lower the chance of failure in a production system.

Answer 4

I spend half of my time researching and the other half refactoring. Almost seriously.

Answer 5

It depends on when I'm trying to learn new technologies or not. I'm currently bringing myself up to speed on WPF and C#, from being a long-term MFC/C++ and other platforms programmer.

So I'm averaging about 3 hours/day on research including a lot of StackOverflow :-D

When I'm in cruise mode, having mastered all the technologies I'm working with, it would drop to about 4 hours/week of reading.

On top of that I average about 1 hour/day casually skimming mailing lists and The Register to keep up to date in general.

I don't refactor code as a mainstream activity, do minor refactorings about 10 - 20% of the time when I'm doing maintenance.

Answer 6

How much refactoring should be done?

Constant refactoring- changing method names, extracting methods, pushing up methods pulling down methods, all as you gain better understanding of the problem and domain you are tackling.

As you work on code you should always look for ways to improve the code.

Refactoring is crucial in aiding fluid and flexible design.

Checkout Fowler's Refactoring book - a must read

Answer 7

I spend alot of time both refactoring and researching. The amount of time spent refactoring is hard to determine, as I do it whilst coding using the Test Driven Development mindset. It's a constant part of writing code. It's not really something I have to get permission to do, I simply include it in my estimations of how long a given task will take, since we use developer made estimations in using Scrum. I often find it's easier to get things done if you don't always ask for permission, given that you don't go overboard.

Researching is approximately 7-10 hours a week, and I'm lucky enough that my boss allows us to spend some time as we see fit during work hours. I research from how to better use Resharper and NUnit to LINQ, design patterns and of course reading StackOverflow and CodingHorror. Even if your employer doesn't see the value in personell upskilling, I would recommend doing it on your own time as it adds alot of joy to the job and if you ever get tired of your boss, you'll have the skills to get a new job :)