The Real World sucks
Being of a reasonably calm disposition, I rarely reach boiling point, but there are a couple of things that really do grind my gears. Inefficiency is one of them, but let's not go there right now. What's really grinding my gears right now, is how much the so-called Real World (as opposed to the academic world) sucks.
Every once in a while, I will stumble upon a piece of code that I really wish wasn't there. It's the kind of code that screams "please refactor me!". It's the exploding septic tank of code smells. When I look at it, the words "well that's going to come back to bite us in the arse" pop into my head. In an ideal world, I'd be able to just sit down for a day and refactor the damned thing. This Real World thing, unfortunately, has something that's called management. Or was it manglement? They're part of Layer 8 either way. That's right, the political layer.
These politics seem to revolve solely around short term benefits. And so refactoring a piece of code that could cause problems eventually in such-and-such a situation isn't deemed important. This is fair enough in some cases, but sometimes you really do know that this decision will come back to haunt you. Sometimes I wonder whether managers really don't care about long-term implications, or whether they like having a couple of big bugs lurking in the code in the hope that some of these will be discovered much later so that we can get paid to fix them. Must be my cynical mind talking.
Is there a good way of dealing with this sort of nonsense? It's always possible to pull overtime and refactor the code then, but what if you introduce a bug? Good luck explaining a bug in new-and-improved code that you weren't supposed to write in the first place.
Yup, the Real World sucks. But if anyone has a way of making it better, I'd be glad to hear it!
January 16th, 2010 - 20:53
Well, I think you can always refactor the code you are currently working on. As long as you are not taking to much time nobody will care or notice. If a bug is introduced it is a unintended side effect of the change. This might happen doing the refactoring or implementing the change. Again nobody knows, nobody cares, as long as there aren’t too many bugs.
For big refactorings, that are unrelated to the changes you are currently making you always need backing from management.
Getting approval for a refactoring like this will most likely take time.
And since management needs “business reasons” to approve a refactoring: Give them reasons.
Tell them what kind of refactorings are neccessairy and why.
If the bug comes back to haunt you, go and tell them.
If you do a cost estimation, tell them that a change would have been half as expensive had you done the refactoring (well, if it is true). This will take time and you will have to repeat yourself over and over again, but eventually you might succeed.
Also management most likely sees refactoring as something that does not add business value. So you have to convince them, that it does (faster implementation of new features, less time for new developers to understand the code, higher quality etc.).
If you were a manager and somebody would ask you to spent some of your scarce resources on something that does no add value, that you cannot control and where you cannot even judge if this really makes sense, would you agree to it? Or would you rather have this resource do something productive and implement a new feature / fix a bug / …?
Can you convince yourself that doing the refactoring adds more value than doing something else? Then you might as well convince management.