For the past couple of months, most of my work has been in that last, most overlooked arc of the development life cycle: maintenance.

Specifically, I’ve spent a lot of time diagnosing problems, tracking down their origins in the code, and making fixes. The client has a strong focus on documentation and process, so the step after a fix is always to write up exactly what changed in the code, and why that change should fix the problem.

If you had spelled out that part of the job to me right at first, it would have seemed irriatating. Certainly not in the top 10 irritants I’ve smiled my way through (#1 = Buzzwords), but one of those things that I’d rather not do, given my druthers.

I’ve turned a cornor, and I’m now actaully considering starting my documentation before changing code.

Twice in the past month, the process of putting a fix into a plain-language description has caused me to realize problems that I didn’t see when just looking at the code.

When it happened today, it was one of those where the fix looked right, but I had that nagging feeling that I was overlooking something. As soon as I started writing, my oversight was as clear as it could be.

This approach should be obvious. I would never start implementing a new feature without putting it into documentation first. I’m first to gleefully predict failure for those who just listen to a problem and start writing code to fix it.