I’ve never heard of such a thing at any company that I’ve worked or interviewed for. Companies normally only want to pay for new features or changes that have measurable improvements for end users (like performance improvements). Refactoring code doesn’t do this in a directly measurable way.

What I’ve witnessed at companies that do understand and care about code quality is that developers are encouraged to refactor code as they work. If you’re going to make a change to a file anyway, you might as well clean it up while you’re in there. Add unit tests, refactor, run a static analysis tool, etc.

This has two purposes. First, the code is actively improved over time without delegating that task exclusively to any developers. Second, time is only spent improving code that needed to be changed anyway. If you have modules of code that are never going to be touched again, there’s not a lot of sense in spending time on maintaining them. They’re not going to need it. Better to spend less time by only refactoring those modules that are most likely to change in the future.

If a programmer knows someone else will be refactoring their code – he/she will NEVER bother to refactor their own work. Setting up a separate team to refactor is like justifying poor quality code existing in the first place. It’s like acknowledging that there will be problems and then modifying your company’s organizational structure to cater to it. I admire your passion for quality code, but maybe in this case it IS better to say “not my job”. Refactoring should be one by the programmer who writes the code, not by a 3rd party who didn’t write it.

Lord no, don’t do this. think of being in the other position – you write code, you commit it, you do some other work, then you’re asked to do some bugfixes on your code, so you notice it’s been updated, check it out and see that it bears no resemblance to what you originally wrote.

You lose a lot of traceability in the SCM too – all those moved and renamed methods mean the code you end up with has no direct trace to the original, it often appears too changed to use the diffs.

so all you’re doing is pissing people off that you sweep in and click a few refactor tools in your IDE, then tell the other coders that you’ve improved it for them. Kind of like Slashdot where you occasionally get people replying sarcastic responses to your post with “there, fixed that for you”. It might be fine if its humourous on /., it wouldn’t be if you did it to my code – I’d tell you it was yours to own from then on and you can perform the maintenance on it.

Now, if you are doing real work on the code, that’s different, but refactoring for its own sake, even under the guide of “maintenance” is just going to annoy everyone else, and that goes double for the “want my group/department to be recognized by management and other groups with this role officially” – can you say “political manoeuvring”? Can you imagine what the other departments will say when their code crashes on customer site? “It was fine when we last touched it, it must have been the refactor department that broke it, they touched it last.”

What you could try is to persuade management that various parts of the software needs more attention, bring the poor parts up and see if they will devote time to improving it. While this happens, you can suggest you take some of the core groups other workload on to add features to the core product. I doubt you’ll get far trying to re-implement core functionality for them, but you will increase your departments ability to add features that can be pushed back onto the core group, then you’ll get more dev responsibility.

It depends on what you really mean by refactoring and maintainability – both in theory and in practice.

We used to have a group dedicated to code cleanup and bug fixes. It didn’t work out so well, because, not surprisingly, good developers don’t want to spend all their time doing code cleanup and bug fixes.

Some organizations choose to have a dedicated “software engineering” team which will tend to spend a good deal of time on code review and mentor the less senior developers on good practices. However, this isn’t a true engineering group unless it is heavily involved in the project plans, architecture, test plans, release process, etc. It’s critical to have this holistic approach, and preferably some amount of training in software or other engineering, otherwise, it tends to devolve into the “cleanup” above.

Bottom line, developers don’t make good janitors in the long haul. And even if you have a true engineering group, that approach tends to work better with cross-functional teams, otherwise other teams may start to ignore or even resent the effort, viewing it as an ivory tower.

Don’t have a room full of developers doing nothing but refactoring and rearchitecting. It won’t end well.

Usually when people do refactoring, everybody does it using opportunistic refactoring. So I don’t think you will find a common name for such an uncommon practice.

But in your unusual situation, even though having everybody refactor would probably be ideal, it sounds like it would make sense to try it.

However, the same political problems that are currently preventing people from refactoring their own code will most likely bring you down as well (which is probably part of why there is no name for what you are thinking of). Will other teams be O.K. with you “improving” their code? What happens the first time you introduce a bug in the course of doing something management doesn’t perceive as that valuable in the first place? What happens when another team doesn’t like your new design?

You can’t guarantee that you will never cost another team some time. And almost any argument that you will have a net positive effect could also be applied to letting them refactor themselves.

It’s possible that what you are proposing will be acceptable yet letting everyone else refactor will not be – but the only way I can picture this happening is if everyone basically agrees that refactoring is a good thing that saves time in the long run but takes time in the short run, and that your team is the only one with sufficient free time in the short run. And if other teams trust you to do the refactorings and are willing to deal with any problems it causes them.

Having a group that solely focuses on refactoring and maintainability and implementing it at the expense of other development groups is dangerous to your organization. There needs to be a commitment from upper management, testers, and all development groups to improve the quality of the code via refactoring to improve maintainability and minimize bugs. It should be everyone’s responsibility to improve the code. When refactoring needs to be done, then it should be put into the release schedule along with the new features. Managers need to be educated and understand that taking time to improve the code will pay off in the long run, because technical debt is what will bring a product to a screeching halt if not paid down as part of the ongoing development process. If all you’re doing is constantly fighting fires from constant bug fixing, the house is going to burn down, because obviously the house is a fire hazard and needs better construction and renovation.

You group sounds more like it should be a architecture/software staff group dedicated to developing the next generation architecture that will be more maintainable. Your group should probably focus on how to demonstrate that refactoring pays off to the “pointy-hair” types, encourage developers with new methods and processes, and educate key stakeholders in management to adopt better code quality and get them to “buy-in” to the process. Come up with a plan to migrate products to a better architecture if anything by laying down a simple foundation first. Take the painful lessons everyone has been learning from supporting your products and come up with a plan to mitigate that pain in the future.

It’s quite common. I’ve worked at a software company where this was the norm. You had teams dedicated to implementing new functionality. Then there was a maintenance team who fixed bugs causing problems for clients. The maintenance team fell under the consultancy/support branch of the organisation.

In that case there were benefits to the developers, namely they worked more closely with clients, even spending time out on site. Product teams doing new development didn’t interact with the clients at all (a hateful situation imo).

It seems more common in software companies and outsource providers that for in house provision. I’m in finance and I can only think of one bank which has used this structure in the past. That said, it’s common that tactical teams might pick up those sort of issues as part of their remit. It’s not quite the same, but similar.

If your team is being under-utilised you need to be a little careful. Under-utilised can be translated into “unnecessary cost” quite easily, so your team of X can become a team of X-1 quite quickly.

A preferable approach might be to spend a little more time on the fixes and incorporate some unwritten refactoring time into the bug fix time.

It does depend on how your company works though. The interesting thing is you don’t really know, so if you have a team lead, it would be worth discussing it with them. If they don’t know, have them talk to the next person up the chain (be involved in that, don’t hand it off). If they don’t know if that would fit in with what management expects, you might fall further into the cost category rather than the asset category.