Take the 2-minute tour ×

So, I work in a company that does embedded software development, other groups focus in the core development of different products' software and my department (which is in another geographical location) which is located at the factory has to deal with software development as well, but across all products, so that we can also fix things quicker when the lines go down due to software problems with the product.

In other words, we are generalists while other groups specialize on each product.

Thing is, it is kind of hard to get involved in core development when you are distributed geographically (well, I know it really isn't that hard, but there might be unintended cultural/political barriers when it comes to the discipline of collaborating remotely).

So I figured that, since we are currently just putting fires out and somewhat being idle/sub-utilized (even though we are a new department, or maybe that is the reason), I thought that a good role for us could be detecting areas of opportunity of refactoring and rearchitecting code and all other implementations that might have to do with stewarding maintainability and modularity. Other groups aren't focused on this because they don't have the time and they have aggressive deadlines, which damage the quality of the code (eternal story of software projects)

The thing is that I want my group/department to be recognized by management and other groups with this role officially, and I'm having trouble to come up with a good definition/identity of our group for this matter.

So my question is: is this role something that already exists?, or am I the first one to make something like this up?

Edit: What I mean is a group driving refactoring initiatives, not doing all the refactoring work themselves. Much like an open source community to an open source product, now that I think of it.

share|improve this question
add comment

7 Answers

up vote 12 down vote accepted

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.

share|improve this answer
I want to agree with this, but developers and business people alike are notoriously poor predictors of what is actually going to need to change, and the longer an individual or team waits before refactoring poor code (especially code with poor or nonexistent tests or documentation), the more brittle that code and any dependent code starts to become. Inevitably it gets to a point where even minor changes are high-risk due to the accumulation of "just this once" hacks and dependencies in other areas of the system, and nobody remembers which parts of the design were intentional vs. incidental. –  Aaronaught Sep 1 '12 at 2:45
@Aaronaught I'm not saying anyone should try to predict what's going to need to change at some point in the future. I'm saying you write tests for and refactor what you know you're about to change because a bug fix or new feature calls for it. Those things that change most often will naturally get the most attention. –  Bill the Lizard Sep 1 '12 at 12:13
I apologize if I'm reading too deeply between the lines, but are you saying that we shouldn't write tests for new code unless and until the functionality needs to change? For legacy code maybe it's a reasonable approach to defer test-writing/refactoring until a change is required, but for new projects - well, that's how they become legacy code. –  Aaronaught Sep 1 '12 at 16:44
@Aaronaught No, I consider new code to be a change to the code base. It should definitely be tested and refactored before being checked in. –  Bill the Lizard Sep 1 '12 at 16:47
I see - so you're looking at this from the perspective of having a (semi) large existing code base that may or not be clean/tested. That's fair. I would agree that there's not much point in doing reconstructive surgery on code that's been in production for months/years. But if the team is putting out fires (OP's words) then that implies that the existing code isn't stable and/or new code is being written that is poor quality, which to me would justify constant/frequent code review and refactoring for new check-ins, and possibly the least stable areas of the application... right? –  Aaronaught Sep 1 '12 at 16:53
show 1 more comment

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.

share|improve this answer
"Refactoring should be one by the programmer who writes the code, not by a 3rd party who didn't write it." ... So you can never improve code that you didn't write? –  sjakubowski Aug 31 '12 at 20:14
He's saying the exact opposite. Let's say you know someone else will go fix your code to be more efficient after you write it. Are you going to make sure it's good, or just passable? –  Shawn D. Aug 31 '12 at 22:14
I've seen a lot of people in organizations operate this way. Except they do it because of what is rewarded (how much code you commit). "Oh I'll just ship this crappy code, and the testers will find all the bugs. In the end I get more kudos for committing all of the bug fixes!! Completely destructive to productivity. –  Ben DeMott Sep 1 '12 at 2:19
@sjakubowski: he clearly means that you never should rely on a third party to improve your code (that does not forbid to improve code from someone else) –  Doc Brown Sep 1 '12 at 8:08
add comment

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.

share|improve this answer
What you're describing doesn't sound very much like refactoring. Refactoring means making small, iterative design improvements while maintaining the existing behaviour, which would be validated by a suite of pre-existing tests. If you're unable to trace these changes back to check-ins, then either you're using a poor SCM or developers are not checking in frequently enough. Developers working on each other's code (including refactoring) is an essential part of the process; if this "pisses people off" then there is something wrong with your process (or your team). –  Aaronaught Sep 1 '12 at 17:21
In fact, it already sounds like a dysfunctional team if developers think that some specific person "owns" a section of code and punts off change requests to that person instead of just doing it. "Hot potato" games don't make for very good code, or good teams. –  Aaronaught Sep 1 '12 at 17:25
consider this guy wants a whole team to do nothing but refactoring, that suggests to me they either want a really easy life, or are going to make major modifications. –  gbjbaanb Sep 2 '12 at 13:12
His whole team is already doing nothing but putting out fires, as stated in the question. That suggests to me that the code being checked in by other teams (or at least some other teams) is of exceptionally and objectively poor quality. Refactoring and bug fixing is hardly an easy life, and major modifications would appear to be what's called for. Why do you think that the person who originally writes code - and a development team - owns that code permanently? Everybody owns and has to deal with all the code, that's how it works in the world of professionals. –  Aaronaught Sep 2 '12 at 15:29
That's a subjective thing based on his desire to take on more of the core product. Letting a satellite arbitrarily decide to work on core isn't the way professional outfits work. So, he's having to fix bugs.. that does seem to be his job, he is a support/client-side team, not the dev team. Besides, he does say his team is "idle/sub-utilised" which tells me the core code isn't that bad after all. Ownership of products is an efficiency thing, they don't have to be the sole people working on it, but it helps to shunt new dev to the team that last worked on that product if possible. –  gbjbaanb Sep 2 '12 at 21:41
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer


