Dev/Test Fight

Today was my third day back in a development role, and it's a bit disturbing how easy it is to slip back into the development mindset, and even more disturbing how hard I have to fight it.

The codebase that I'm working on updating was outsourced to a coding sweatshop overseas. While I've seen some wonderful code come back from outsourcing partners, this code is closer to the code I'd write on a Dvorak keyboard while high on NyQuil and NoDoz.

My current task is to add two pieces of additional functionality without breaking any of the old functionality. Unfortunately, the codebase is so fragile that looking at it funny causes the server to dump core and fling it at the sysadmins.

The developer in me is thinking that a trained chimp could do better than this monstrosity, and that I'd be best served in the long run by rewriting the mess of code in a clean three-tier setup rather than the partial-one-tier abomination I'm working in. The tester in me is trying to minimize change as much as possible. After all, while the code is fragile, it does work. The code is in production. The tester in me wants to restrict change as much as possible to limit the chances of my code breaking anything else.

I've ended up compromising with myself. The new code that is going in is being written as close to a clean three-tier architecture as possible. If I can cleanly plug into the current system with a one or two line change, I'm doing that. If not, I'm planning out how to refactor that section of code to allow the clean add, refactoring the code bit by bit and testing each step of the way, and finally integrating my new code. I'm also adding in comments as I delve into the old codebase so that later, if a full refactor/rewrite is done, there are some landmarks that can be used as guideposts.

It's slower, and the old code isn't improving very much, but I'm not affecting the stability of the product and I'm getting the functionality in.