So why are you 'refactoring'? It works already, right?

'Neatness' in code and company philosophy is a variable preference, ranging from OCD to MS Word.

Messy code probably isn't a problem so long as no one is trying to change it. Maybe a little speed decrease, but for most of the projects out there, that speed is not a big problem [citation needed]. Your manager knows this, it's what they are trying to say when they come out with 'it's been working fine for x months now'.

So how do you share the value of neat code and refactoring with your manager? Well, you translate it to business value.

What's the business value of a neat storage room? If you keep throwing things in there and closing the door behind you, it will probably be fine for a while, but one day someone is going to want to find something in there, and it's going to take them ages. It might even be an emergency, you never know. Oh, and we have rats. Well we think we do anyway, we can't see anything in there. Actually, the whole team is scared to go in there because we might break something. Sound familiar?

It's probably a challenge to convince the boss to have a 'storage room cleanup day', especially if there are only a few valuable staff who know where everything is supposed to go. You definitely should keep it clean to begin with, but we are talking about a room which has gotten WAY out of hand, but if you can have a conversation where they get the value of what you are proposing, you are in with a much better shot.

Never 'Innocently' break something big by making a small change to prove how spagetti the codebase is. To do that is to forget what the manager is seeing. Chances are you have inherited this mess, so they see some code which worked when the last guy was here, and is broken when you are here. So you broke it. Even if it is your code, you want your newfound respect for neatness to be seen as better - which for the managers means 'stuff is working'.

What when you are calling the shots? My neatness theory worked really well when I was coding for someone else. When your job is just to code, you code well, but when your job is to provide products before deadlines for budgets, things get a little hazy.

• Does your customer care what your code looks like?
  • Can you fix anything which breaks quickly?
  • Can new features to be added easily in the future?
  • Would you like to inherit the project you are now working on?
  • Is getting paid to meet a spec your main driving factor? (There's nothing wrong if it is or if it isn't, just be clear with yourself)