Friday, November 09, 2007

Shades of Laziness

I'm currently maintaining an EOL system. As soon as I found out that the system was EOL, my development approach took a 180 degree turn. No longer do I have to think of the long term ramifications of my code. I no longer have any reason to refactor. Indeed, I would be irresponsible to do so since refactoring always comes with the risk of introducing new bugs and I would be adding to the workload of the business analysts (who are also the QA engineers) since they are doing the double duty of working with this old system and transitioning to the new.
I even came across some support for my position after the fact (see "Delaying Development Expense").

So now I'm free to be a lazy developer: throw code in the UI layer, add small hacks where I would usually refactor to allow for proper addition of new functionality; simply do the quickest, easiest thing. It's amazing how much less time this requires than "proper" development. Of course, if the system were to stick around, ever more time would be required. This kind of lazy is different than the good kind of laziness in a developer; I've traded one lazy for another.

One thing that is actually liberating is the fact that I no longer groan at all the ancient bad architecture in the system that I formerly had to work around. Architecture is completely irrelevant; no given architecture is better than another at this stage - it's no longer a beast that I must fight.

Liberating though it may be, I think I'd rather have my old lazy back.