Maintenance Downside

Just over sixteen months ago, I was laid off by Ritual Entertainment. Since then, I've gone from being a contractor with problems getting paid to Senior Programmer/Analyst at my job. (By the way, it's sounding like Joshua Herman is back to his check-bouncing ways according to a commenter.)

Over the last sixteen months, my primary job here has been doing maintenance work on a fairly large existing code base. Coming from a QA background is actually very beneficial when you are doing maintenance work. You understand that even the smallest change could cause unforeseen consequences. It may take me a bit longer to go through and find the smallest possible change to get the desired effect, but as a result the number of changes of mine that result in major issues is very small.

There is one large downside to doing mostly maintenance work, though...you get rusty when it comes to making a new project from scratch. The two have completely different mindsets associated with them.

When I'm doing maintenance work, I have a large existing code base and my focus is to make my change in such a way that the rest of the house of cards doesn't come crumpling down on top of me. That involves refactoring where appropriate, careful analysis of dependency chains, and fighting the urge to tear out the entire code base and start from scratch.

When I'm doing new development, I have a blank slate and my focus is to get to a functioning system as quickly as possible. That involves creating code that can easily be refactored, creation of simple dependency chains, and the willingness to see that I've made a large scale architectural mistake, tear out the entire code base and start from scratch again.

Generally when I'm doing new development, I plan out enough time for me to make my prototype, get it functioning at a basic level, and then scrap the prototype so I can build the product based on the lessons learned while making the prototype.

Regardless, the amount of maintenance coding I've been doing has been affecting my ability to effectively write new code. If we weren't short-staffed, I'd probably take a one-week sabbatical so I could work on a 40-hour project just to get my sea legs again.

After all, the only way to get used to writing new code...is to write new code.