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"?
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.
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.
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).
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.
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.