Take the 2-minute tour ×

My company is inheriting a large code base for two products that's fragmented into different applications using different languages and technologies, with a significant portion of it spaghetti code. I'm the only in-house IT person, and while I'm confident I could maintain the software for current operations, I don't have the expertise to refactor it into a more maintainable form. With the approach and development choices being entirely malleable, would a role like this appeal to a senior developer or would "we have a bunch of bad code" cut off "and are intent on improving it correctly"?

share|improve this question
For the sake of us all don't refer to yourself as a "resource". A little bit of self-respect is good for the soul. –  user8685 May 5 '11 at 15:22
@Developer Art - I certainly didn't mean it in a dehumanizing way, just thought it sounded better than "IT person", and "IT employee" rhymes too much. –  John Straka May 5 '11 at 15:28
That's how HR thinks of programmers - replaceable resources which can be combined and thrown at tasks. We must stand our ground against that notion! :) –  user8685 May 5 '11 at 15:32
Changed per popular demand :) –  John Straka May 5 '11 at 15:37
add comment

5 Answers

up vote 15 down vote accepted

Other job considerations aside (location, etc.), if I saw a job posting with the description "we've inherited a bunch of code that we know can be better and we want a senior developer to refactor it for us to make it easier to maintain", I would be applying IMMEDIATELY.

I spent about ten years dealing with code bases inherited from other organizations, and refactoring was almost never a primary task. I know that most of the devs I worked with were constantly frustrated to have to work with code bases that clearly could be improved and made more maintainable with a good up-front refactoring pass. Any one of them would have jumped at the chance to make refactoring a primary task.

share|improve this answer
That's where you want to ask the question "If I started today, what would I be doing" during the interview. 10/1 odds the answer isn't "refactoring code", it's "Well... we have this one new feature we want to add, can you do some refactoring along the way?" –  Brook May 5 '11 at 18:41
add comment

It depends on the person. Some people can't stand looking at other people's code and want to write everything themselves. Working with legacy code can be very frustrating because it may not appear to be logically organized or uses a different formatting style than you are used to.

Other people are very good at looking at existing code an being able to think of ways to better implement them. Performing this task could actually be seen as a nice change because (hopefully) the requirements would already be well defined and there would be test that those goals are achieved.

share|improve this answer
Exactly! I probably would not mind doing this for some time if I were looking for a job. –  Job May 5 '11 at 17:55
add comment

I think it would appeal to some senior developers. But I think you also have to offer a good degree of support and autonomy. For example, I think you have to be open to letting the developer investigate and choose ways of updating the baseline of the code with newer technologies. Also, they should have some degree of control over cost and schedule and what features get updated in what order. If you are hiring someone senior, they should be able to step back and balance business needs with technical limitations, and you have to give them enough ownership of the project to keep them emotionally invested. If the job is jumping when you are told to jump, it will be hard to retain any developer (junior or senior).

share|improve this answer
These of course are considerations, we're hoping to find someone who's looking for that level of autonomy and has the expertise to make the right choices with it...there's no one here to effectively order the jumping. –  John Straka May 5 '11 at 18:18
Good point! Without a higher level control and support from management and business, a senior developer will just repeat whatever already have happened, resulting in a new "legacy" system, of cause in one language, if you prefer. –  Codism May 5 '11 at 18:18
add comment

I think it would appeal to a senior dev.

Chances are most people would be sceptical that the role would ever really become "rewriting from the ground up" etc, and would just end up being a patch job like you currently do.

share|improve this answer
add comment

You would really need a mutli-discipline team to make this work

Although the idea of one IT person tackling the many-headed hydra that is the current legacy codebase sounds heroic, in practice it'll be extremely hard to accomplish. Day to day distractions will slow down the progress and it will be very hard to convince management that the work is actually going to pay for itself in the long term. Also there is the problem of one person having all the domain knowledge and no-one to take over in their absence.

Essentially there are several possible approaches (TL;DR -> skip to number 4):

1 - Do nothing and carry on

This works in the short term but accrues technical debt. Eventually the system will be such a mess that it becomes impossible to make changes without incurring the wrath of the your customers. At that point a rewrite is almost inevitable - but you may have lost many of your best people along the way due to frustration.

2 - Attempt to fix it as you go along

This is the approach to take if management haven't really bought into the idea of technical debt, or changes are minimal. As each new fix or feature is added then developers are made responsible for introducing the appropriate automated test that demonstrates that the code works as expected. Over time those parts of the system that need maintenance will get improved and have the safety net of a test in place, while those that never get touched are left alone.

This works sufficiently well to make it viable but takes a long time to reap rewards.

3 - Perform a parallel rewrite

This is often favoured simply because it offers such promise of solving all the problems in the old system. A problem can arise if no-one has learned the lessons of why the old system rotted so badly and repeats those mistakes in the new. This leads to the potentially catestrophic result of two failed systems.

There is also the problem of adequately specifying the new system so that it does actually both replace and improve upon the old system. This inevitably requires a comprehensive review of the old system and possibly even a set of regression tests to prove that the new system is behaving the same as the old (including failures and bugs until refactored and fixed).

4 - Wade in there with a refactoring team and make it a priority

This approach will pay off in the long term but will cause significant pain in the short term. So long as your management team have bought in to the idea of what you're trying to achieve and are convinced that a rewrite is not the better approach then this may yield the best overall result.

The refactoring team should be able to introduce best practices and disseminate that knowledge throughout the team as part of a continuous stream of updates and change notifications. Regular team briefings showing what has changed and why would form part of this process.

This is where a senior developer will shine and may ultimately prove to be the task that attracts them to the job in the first place. The opportunity to show how things should be done in comparison to what is going on at the moment should be senior developer gold, especially if they get free reign to fix things properly within the context of a team.

share|improve this answer
I still have one foot in operations and one in development, so I've tried to do #2 as I acquaint myself with the programs and have the time. Management completely recognizes how untenable #1 would be. Last paragraph is definitely what we're hoping to happen. Thanks for the very thorough answer. –  John Straka May 5 '11 at 18:22
add comment

Your Answer


