Tuesday, September 09, 2008

The zen of software maintenance

We're kind of in a middle phase of our current software project. In the last few weeks we've been focused on fixing as many defects as we can and getting it as stable as possible. Thus new feature work has been neglected a bit.

So pretty much each day was come to work and knock off as many trouble tickets as we could. Now some might find this distressing, focusing on fixing things over new design. But I find I kind of liked it. There's something good about hardening a system, making it better and more stable and enjoyable to work with.

In fact sometimes I could convince myself that it wouldn't be bad to do software maintenance all the time. There's some nice things about maintenance. First of all the objectives are generally clear. The defect is known and reproducible. Fix it. That's nice. Plus you know when you're done. If it goes from not working properly to working properly then you're on the right track. There's a certain satisfaction in going from non-working to working which I find pleasant.

With maintenance it's generally easier. No one is looking for grand sweeping architectural visions or elegant designs. It's just modify the design that was done, the decisions that were made, so that the execution is corrected. Rewrite is costly and generally frowned upon [as it generally should be]. So it's less taxing in some ways.

It's a bit strange for me because in the past I was always focused on being involved with new applications, new code, new systems, new technologies and tools, big new fresh things. But now I'm seeing enjoyment in caretaking the big things other people may have built in the past.

I guess I'm getting older and probably mellowing out some. I'd say based on if my health can hold up and my finances I have 10-30 productive years left. Maybe I'm at least thinking about transitioning to new types of tasks for the upcoming phases in my career.

Now that I've picked up some JSP in the last few months, it is possible that with my background in Ada, Oracle Forms/Reports, and more recently Java that there might be enough legacy code around that I could work with these technologies the rest of my career and not have to learn any big new sweeping technology or paradigm. Especially with Java which hasn't peaked yet and major new blocks of tomorrow's legacy code are still being created today.

But why just think of it in terms of code to write? There may be other roles available that I'm a good match for that are a good transition from where I've come from the last decade+. It's at least worth thinking about.