Every application goes through the full SDLC unless the project gets cancelled. No matter what the methodology implemented to manage the SDLC there is one consistent fact: All software must be maintained once it is built. No matter what one architect at my client says, no application is 100% self healing. Someone, whether they are from the original development team, original development company or someone totally removed from the initial development process, has to monitor and respond to the application.

Unlike creating an application from scratch or extending the functionality of an existing application, maintenance requires the developer to be much more conservative in their approach to the code. Yes this will vary depending on the maintenance situation. My experience has been that maintenance programming is more about code and functionality analysis than it is about fixing the code. Your job, first and foremost, is to triage incoming issues.

If you receive an issue and your first instinct is open the code and start changing code, you will fail as a maintenance programmer. Your instincts need to take you through the following steps:

1. Repeat the reported issue.
2. Determine the exact current system functionality and the reported desired functionality.
3. Research the specifications that were agreed upon design for that component of the system.
4. Determine if the reported issue is contrary to the agreed design.
5. If the reported issue is because the application is not to spec, then begin to fix it.
6. If the reported issue is part of the agreed spec, return it to the business with an estimate to change the behaviour of the application.Because you must consider the agreed design (spec) of the application for each and every issue that is escalated to you, having solid spec documents to fall back on is very advantageous. The stronger the spec document is the easier it will be for you to prove to the business that the application is meeting a specification that they agreed to. This isn’t to pass the blame or to avoid changing the application to meet the business’ desire. Instead it’s to give you, the maintenance developer, a solid platform to stand on when you being negotiating the proper solution for remedying the situation. After determining the validity of the reported issue, the maintenance developer has to do one of two things: Fix the defect or negotiate a change to the application.

Maintenance developers require great analytical capabilities, strong business sense and the personal character strength to take a position in front of the business and argue it’s merits. More than any of those though, the maintenance programmer must have patience. Patience in the face of the panic phone call where the client claims the sky is falling. Patience in the face of SLA deadlines. Above all patience when receiving an issue. In the end, maintenance programming is more about maintenance than it is about programming. If the developer in this role can’t go with out their coding fix, they will not last long. Not because of lack of skill, but more because of boredom.

The last four months have been some of the longest in my professional career. Nothing makes me prouder than knowing that I worked on an application that has a very minimal list of reported defects….until I realize that that small list means that I’ve had very little to do while maintaining it (by no means is this a recommendation to intentionally insert defects so that you have something to do during maintenance). I’ve never performed this role before, but I’m glad that I stuck around for it. I have a far greater appreciation for what should be included in the code deliverables in order to help the maintenance person succeed. A number of times I have found myself wishing that I’d created unit tests for certain functionality (we were not a TDD shop). I also have gained an appreciation for the time spent developing and updating the design specifications. Very early on I found them to be my gospel and the only items that I had to back up my claims during triage.

Although maintenance programming is a difficult and often times extremely boring gig, it’s one that I think any developer looking to move up to roles such as team lead and application architect should have to do before being placed in their new role. It provides a very different, and very valuable, perspective on the SDLC.

I’m the Igloo Coder and I’m hoping that my triage days are very close to ending.