How to convince management to clean up code after going live

Question

At one of my customers I more and more often run into the situation that we are not given time to "clean up" the code after we've gone live. How can we convince management that this would be time and effort well spent?

Some more explanations: Typically, there is a mad scramble to get things properly working in time, and after the internal customer has accepted the code, I would typically like to spend some time. For example, there are handling issues and internal things that the internal customer does not really care about, but I'm sure that these things will pay over time by making the code more readable and easier to understand, so fixing bugs that may turn up over time or changes that are required will be easier to do.

The counter arguments do make some sense .. there is risk associated with changes, the need for the internal customer to do acceptance tests again, generally with some assurance that we will take care of things "next time" when we have to work on the code.

Answer 1

Unfortunately I don't know that Management cares how readable code is, or how clean it is, or how scalable it is. They care if it's working or not. And in many cases, is it making money.

A friend of mine once expected to hit the management-wall regarding post-production-cleanup, so he planted a few sleep() commands in the app to cause it to run slowly. When demoing it, he would constantly assure management that "This can be improved with some cleanup." They gladly encouraged post-production cleanup at that point, because they could SEE the need.

It's a little deceptive, but it worked. In the end, the app was cleaner, faster (obviously), and well-written.

Answer 2

The question you should be able to answer before suggesting any change is, "How does this make us money?" If there's no good answer, a change may genuinely not have a good business case to be made.

As developers, we always want to improve the code, make it more elegant, etc. But, very few of us have the luxury of approaching programming as an art rather than a business tool.

For changes that have nebulous business cases, you can often come at them as part of a larger fix with known value.

Answer 3

Ask for time to write unit and functional tests. You'll catch more uncovered bugs, refactor the code and leave some serious artifact of the invested time and effort.

Answer 4

I typically try to work the "clean-up" into the next sprint right after the release. The way I explain it to the management is that we had to take some liberties and shortcuts with the code to ship on time and now, in order to grow the product, we must improve the foundation.

Hope it works out for you.

Answer 5

One excellent metaphor that really captures the attention of business-types is referring to it as Technical Debt. That makes them understand that while it's not an acute problem right this minute, it'll grow worse over time if ignored, and there are real monetary ramifications if you don't deal with it.

Answer 6

The counter arguments do make some sense .. there is risk associated with changes, the need for the internal customer to do acceptance tests again

These don't just make sense, they are killer arguments. Even if you had decent test frameworks etc, there is always some risk you'll break something in 'cleaning up' the code, and there is little or no benefit to gain.

If it cannot be done right the first time, then you need to wait for the next change requests and do the work then. Of course, you can work ahead, but you need to wait for the next release and run the release process again.

edit: to expand on this, if you had a bug fix or change request, you could also clean the code up some at that time. But until you have that, you're just wasting time unless you actually have nothing else to do, which seems unlikely.

Bottom line is if the code wasn't clean in release 1, the cleanup can only be part of release 2. And if there isn't a release 2, or you haven't got time to work on it yet, you may as well forget it.

Answer 7

Well put yourself into your managers shoes: you are paid to write the best code you know. And then you write something you know it isn't OK and would need additional work. Why would they pay you for writing crappy code and then again to fix your crappy code knowing you could do better in the first place...

I know there are cases where there simply isn't time to do something 100% right, but you are talking about full blown projects here (as far as I understand)...

Answer 8

You could try to argue that after the initial "go live" there should be a maintenance and support time where any production issues not caught before get patched and handled and that this is also the time to prepare for any future enhancements or bug fixes. If management can say and agree that "We won't ask for any more changes, ever" then I don't think there is a good reason to go back and clean up code unless one believes that such a claim isn't good in perpituitiy or like Dr. House would say, "People lie."

Answer 9

The question you have to ask is why this isn't being done while the code is being written the first time. What you need to do is plan time into the release to fix the code being produced. If management won't give more time, then the processes the programmers follow need to be more efficient. That is really the key. Things like writing specs beforehand, planning out what is going to be done before they do it, writing unit tests, and having code reviews.

I know that is a copout answer, but really that is the way to go about it. The response of there just isn't time to do it is kind of a fallacy as it is really "We don't have time to do it the way we develop software." Does that mean that you need time to refactor everything that is written at that moment? No, there will always be things to change and make more efficient, but code needs to be written well the first time, so a small amount of refactoring is needed down the line.

Answer 10

It's really hard, really amazingly hard. But the best thing to do is to get the code right to begin with. There just may not be time later.

Answer 11

Let's say you're doing Test Driven Development and so your development process should go something like this:

1. Write a test to cover the new functionality required (test fails)
2. Write code to make the new test pass (along with all others)
3. Refactor the code
4. Make sure all tests still pass
5. Check your code into source control

Except, in your case, you are jumping from step 2 to step 5 (skipping steps 3 and 4) - and now you want to punish management for you doing a quick and dirty job. Effectively, you are going to management and saying "We want to rewrite the entire application which the customer has already accepted and paid for, add no new functionality, spend loads of developer time doing it for which you won't get paid, and potentially introduce new bugs just so we can make the programs prettier to look at for us developers". Nobody is going to go for that.

An important point is that you don't know where you need to make the code more understandable - most of the application may never have a developer look at it again and go on working forever, as ugly it is.

Think of this in the same way as performance tuning - you only tune the areas of code that demonstrate that they are slow and need tuning. In the same way, the time to refactor code (for an existing project that hasn't been refactored while developed) is when you go into part of the code again to fix a bug or add a feature and the code isn't understandable. As part of gaining an understanding of the code, refactor it and make in more understandable - if the tests still pass, then you've understood it.

The thing to do now is not go to your boss and say that you did a crappy job and you need to stop doing paid work in order to make the code prettier. The approach to take is to explain about technical debt and let your boss know that in order to meet his deadlines you cut a few corners and for future work there will be a slight increase in the amount of time taken to do the work as you make the code better. Also explain that as you do this, the time taken for fixes/features will reduce but if you don't do it development will take longer each time something needs to be done and the code base is likely to get less easy to change and the application will become more fragile.

Refactoring the code that you come in contact with as you go forward allows the code cleanup to be done only for the code that needs it, when the work will be paid for.