I'm currently working for small company that has few technically complicated products. I'm the one and only developer for one of them. About a year ago, I got the legacy version of the product and started "supporting" it.

Customer only talks about new feature, business value and others of that kind. The problem is, though the code is in C#, it's quite procedural. There are no abstractions, classes are only used where Visual Studio requires them - Forms, for instance. The implementations of these classes are really awful and the code is really hard to maintain.

For all these year I spend my own time for refactoring. In the latest version, there are pretty abstractions and such. I had to reimplement a number of components from scratch and I really feel that adding new feature or changing behavior to these components is MUCH easier than to others.

The problem is, I spend my own time. I really like the results, but I don't like working 12 hours per day. Have you ever been to similar situation? What should I try? I've already tried discussing it, but still no success.

I'm just scared of the moment when we decide implementing the new feature that requires a lot of changes to the legacy code. That just could be shocking to the customer: why do you need 8 hours for changing these icons? The customer just doesn't care that there are 500 places in the code that I need to change. And I should also find all these 500 places first.

Any ideas?

  • 3
    What is your question? If you are an employee, why do you have this code and why have you modified it on your own? What do you want? To be compensated for your unpaid time working on it? Or just to work less hours? Does your employer know you made improvements on your own time? Your question is unanswerable as it is currently written. Jul 19, 2011 at 20:24
  • 3
    OK, so what is your specific question? Why would you want to keep it procedural if the architecture you developed on your own time is better? Jul 19, 2011 at 20:28
  • 8
    They do not speak your language, so you need to learn theirs. This is how it is very OFTEN. This is no reason to run away, for it is like this almost everywhere. You need a half-true-but-plausible reason to bring in another GOOD coder on-board, and then build the re-factoring time in. Otherwise do your best to pad your own estimates and add re-factoring time to any project you do. Business folks usually have a soft spot somewhere. Some tasks are bigger than others in their eyes. Pad the "large" ones. Oh, and do not forget to write tests :) Also, keep doing the overtime for now - invstmnt
    – Job
    Jul 19, 2011 at 20:28
  • 2
    @Robert Harvey, the asker knows how do do things right, but is stuck with someone else's crap and is the only one who sees many risks, is the only one whos fault it is when crap breaks. The small business is trying to survive and is sales/revenue - aggressive, but the mounting technical debt is stressing him out without others recognizing it. He needs a roadmap and tips for how to get out of this hole.
    – Job
    Jul 19, 2011 at 20:34
  • 1
    I've changed the title of your question. Hopefully the new title more accurately reflects your intent. I'm not sure you can recover the lost hours; I would do what others suggest and add some padding into some of your estimates so that there is some money available for incorporating your enhancements. Jul 19, 2011 at 20:35

10 Answers 10


Step 1: Stop working unpaid overtime.

You have already trained your customer and manager for a year to believe that the current rate of development is what should be expected. This is part of the reason why they do not understand why a "simple" thing could take a full day to do. You don't need to hold them hostage and attempt to hurt the project. But you need to explain that their expectations are too high and you either need another developer or more time before the deadline. Make a point to specifically mention to your manager that you have been working unpaid overtime and are planning on not doing that as much. Even if you cut it down to 9 hour days, the difference will be noticed. If your manager asks you why you are not getting your work done, you can point to the fact that you made a point to warn him this would be the case.

Step 2: Make notes

Just because you don't have time to do the work, doesn't mean you can't make it easier when the work (hopefully) gets done. Keep track of ideas you have for fixing the code and bring them up at meetings so others are aware of your concerns. Eventually you will hit a slow patch or people will start to understand your concerns have value. When this time does come, you will already have some basic ideas about what to do instead of coming at it dry because you haven't looked at a section of code in a while.

  • what you say are absolutely great ideas. About a month ago I've decided to add tasks in our bug-tracker. I don't care that this task are not confirmed, every time I see potential problem, I add task and notify customer. The next time I'll have to fix something I've been expecting ASAP, I just remind the customer about the task that I've already created few months ago. Hope that helps. Jul 19, 2011 at 20:56
  • 17
    "Stop working unpaid overtime" should apply even if you absolutely love the job. You are not benefitting from your extra hours; they are. If you want to spend the time in front of the computer, do it for your projects, at your house. Jul 19, 2011 at 22:36
  • 1
    After more than a decade in this industry, I still have never "hit a slow patch". What am I doing wrong?
    – sbi
    Jul 20, 2011 at 9:29
  • @sbi I think that could be "doing it right" :)
    – Stephen
    Jul 20, 2011 at 13:08

... the code is really hard to maintain.

This is your way in with management. Demonstrate that the cost of "just" fixing the bugs and adding new functionality is greater than that of refactoring and rewriting the code.

For example if with the current code a new feature would take 2 weeks to add and then a significant amount of time to maintain (e.g. 1 day a week), show that with a week's refactoring you can get the development done in 1 1/2 weeks but that you'll cut the maintenance down to 1 day a month (or less). These numbers will show that what you are doing is cost effective in the medium to long term even though there is a short term cost.

While the company might not like spending the money now, they'll see that the potential benefits are much greater - i.e. you will be more productive generating more code in less time and that code will be better quality.


Apply the Boy Scout Rule: Leave the code a bit tidier (i.e. with less technical debt) every time you touch it.

Allow time to do this in all estimates you give. Then, magically, over time the technical debt will dissappear and you will have been paid for doing it.

This approach is much easier than explicitly trying to carve out time (and therefore convincing customers / managers to pay) for technical debt. It gives you a much greater feeling of professionalism and a "job well done". And finally, your customers and managers will thank you for it in the long run, even if they don't quite understand how it happened.....

  • However, this approach will make it impossible to do any more substantial refactoring.
    – sbi
    Jul 20, 2011 at 9:28
  • 1
    @sbi - you'd be surprised: if you have good unit tests in place and decent SCM for rollback then you can do a huge amount in controlled, verified steps. I once changed a large (50+ class) inheritance hierarchy into a prototype-based model in a series of incremental refactorings, none of which needed more than a couple of hours work.
    – mikera
    Jul 20, 2011 at 10:04
  • @sbi: One should never actually do substantial refactoring - just one change / refactoring at a time. Small units of work, small changes, and of course running all the tests and the like to make (doubly) sure you didn't break anything.
    – cthulhu
    Jul 24, 2011 at 20:25
  • @Cthulhu: If you have good unit tests, you can knock down and rebuild almost as much code as you want, since the tests will catch most errors.
    – sbi
    Jul 25, 2011 at 0:04

This is more or less the sad reality of maintenance programming. You are stuck with what you get assigned to maintain and if the person paying the bills doesn't want to pay for what he considers to be changes without benefit, then those changes tend to not get done.

If you want to make the case for getting these changes funded, then keep a log of all of the places that you have to change for even the simplest update. After a few changes, discuss that log with your manager. If you can document it, there is a chance (albeit very slim) that the person with the purse strings will realize that it is actually cheaper in the long run to clean the code up now as it will make future changes cheaper.

Your chances of selling this increase the longer this product is expected to be in use. Odds also increase if a failure in the product is likely to cause a public relations issue for the customer or cost the customer money.

Barring that, learn what you can and move on to another position with less maintenance.


You need to show your management how refactoring and otherwise improving the product will benefit the company.

The customer is not likely to care whether the code is beautiful or ugly so long as it works, and management won't be eager to explain to the customer that what they've already paid for was badly designed and poorly implemented. At the same time, management will not be eager to eat the cost of development time that doesn't improve the product in some visible (billable) way.

So... you have to convince management that the changes you propose will help the company:

  • Show them that a better architecture will allow you to add new features more quickly.
  • Explain that by continuing along the current path they'll be painting themselves into a corner.
  • Give examples of changes that are very expensive to make in the current system, but which would be simple and cheap with a better design.
  • Keep track of time spent maintaining legacy code vs. adding saleable features. - Help them explain to existing and future customers that while the existing system was pretty good, the new, modernized architecture will allow many great new improvements, better reliability, and so forth.
  • Mitigate the risk associated with the changes you propose. Managers are risk averse, and sweeping changes to an existing system seem inherently risky.
    • Prioritize modernization of the various components according to cost and benefit, and make sure that management agrees with your priorities.
    • Use unit testing to help ensure that modernized components will be compatible with the remaining legacy code.
  • Track the progress of the modernization effort. Show benefits as soon as you reasonably can, but remind all parties that there's more work to do.

You may not realize it, but Johnny Cash predicted the refactoring movement and wrote a song about the best way to refactor a large existing code base.

Of course, he had to wrap it in an automotive metaphor so his audience could relate to it.

"One Piece at a Time" - Johnny Cash


It seems like you could charge the customer for the time the change "should" take and still come out WAY ahead in the long run.

If you enjoy cleaning up the code (and it seems like you do at least a little) then go ahead and keep doing it but don't burn yourself out on it. That doesn't do you, your company, or your other customers any good.

Make sure that your management and anyone working with the customer knows that the code isn't in the best shape so they can make an informed decision - just because you own that code doesn't mean you should be making the business decisions about it, if they aren't aware of the problems with the code then they can't do their jobs.

  • 1
    @robertharvey: yeah he's cleaning up the code on his own time so that the customer that would be billed for updates doesn't have to pay more than if the code was well-written. I think his company needs to eat the majority of the costs (if they occur). It's reasonable that the customer pay some of the time, but if you overbill because the code is crap that's a good way to lose good-will and future business.
    – DKnight
    Jul 19, 2011 at 20:39

Although the client's application has some technical debt, don't forget, they probably were charged at a slight discount. They may not have been made aware of this, but that's what happens when you take the lowest bid.

They need to decide if they want to pay the full price for the feature changes or do without them. It's their choice. You can let them make the decision or continue working for free. You can try and mention the cleanup work you did and offer a slight discount for the work completed. Again, it's their choice.


The way I would approach this is to start with explaining the concept of technical debt to your bosses to make sure they get it. Approach it from a bottom line, business perspective. Every time they request a new feature, the technical debt built up in the product affects your efficiency, and therefore each feature costs a bit extra due to this debt.

Once they understand what you're talking about, try to negotiate for a bit of your time to put toward reducing technical debt. At my company we've been reasonably successful with petitioning for 10% of each developers time in order to work on technical debt reduction.

Once you have some time set aside to work on this, make sure you actually use it (and don't just work 10% overtime to do it - stick to your guns). Create a catalog of technical debt items and prioritize them and start carving away. You have to eat the elephant one bite at a time.


And don't forget to factor in better tools. Resharper is a great refactoring tool that plugs into Visual Studio.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.