Get maintenance involved in your project. Early.

Last week we had a meeting with our contact at the department that will be maintaining the software we’re going to be developing in our upcoming project. Normally, these kinds of meetings take place in the end of a project, sometimes even under some (release) stress. At least, that was the case for all the previous projects I was involved in at the customer I’m currently at. Most of the time this is because people want to start developing the software instead of thinking about things that are not necessarily their area of expertise.

For this project we did things a bit differently. This is because the rough outline of our project is pretty clear, but the business analysts are still working on some (pretty important) details. Because of that we had the time to get a pretty good idea of when we will be done, and to for instance make a proposal for the deployment model for our solution. We made a diagram, took this to our contact and asked his opinion. Because of his expertise, he asked us some questions which normally would be forgotten up until the moment the solution was going to be released, or would never be asked at all. He also gave us some pointers, and a few whishes out of a maintenance point of view. Because of this we can help maintenance by taking their hints and making the software easier to maintain.

I already have the idea this is a better way to work. It might be because of the fact that it’s easier to “get things done” from maintenance (there’s lots of time before it has to be done?). But I’m absolutely sure it is because the software was thought through from different viewpoints. Not only the testers and developers have had something to do with it, but the people who have to keep it running did too.

• Methodology