Steve, I know that it builds dread in the life of developers. Long term maintenance of day to day issues can drive some developers to seek employment elsewhere. And these are both the talented kind of folks and the lazy type. Once a system is deployed and the burn-in period of four months or so is done the project goes strictly into maintenance mode and those who are selected to maintain the code do such.

There are then three lines of defence. First the Ops staff who are skilled professionals can fix some of the things that go wrong. Second the selected maintenance team is engaged. This group has had some significant knowledge transfer and experience with the developers and the code. They can find the majority of the problems and are empowered and required to fix them.

If the two previous groups cannot find the problem the original development team, writes of the code and the development team architect or strategist may get involved. No one knows the internals of the project better then those who conceived and developed it. To not have this team involved in some way is to put the operational system as a significant level of risk, and will lead to a quicker redevelopment of the system. If you cannot fix it you have to rewrite parts of all of it.

So yes the developer is involved heavily for four or so months and they should be directly involved with knowledge transfer to the maintenance team. But they remain involved such that if others cannot fix it they can.

M.