S'true

Much has been said on why development projects should handle maintenance themselves. Maintenance in this case means the process of fixing bugs and/or adding extra functionality after the first release. One of the main points of why is that there will be sub-optimization in the initial development project if the people in the initial project don't feel responsible for creating a maintainable system. In the initial development, the dev team cuts corners to be able to finalize as quickly as possible. This is often increased even more if the projects runs late, which lots of software projects tend to do.

Some of the stuff that may be cut by a project are automated tests, general refactorings and thus thoughtful software design. I've heard stuff like members of the development team reasoning like "It runs, I'm ready", which is kind of scary.

Another big advantage is that the knowledge in the initial project is preserved after revision one. If the initial team knows that it will disband after the first release, there will be a high focus on writing documentation, even though the team may run an Agile process without a high documentation focus. If the organization knows that the team will stay intact after release, there will be a smaller push for extensive documentation. Instead the organization will rotate in and/or out people gradually, and there will be no big-bang knowledge removal.

The above is an example of one of the lean practices; optimize the whole.

But now on to the next step.

I propose another work principle for the project, namely to internalize the IT operations to the development project. This means that there will be a percentage of the total time spent in operating the servers. Everything that is to be installed/patched is done by the project team.

One effect of this is that there is no buffering in the feedback to the team. The process "Bug in product -> Defect in the bug tracking system -> Failing unit test" will be the shortest possible.

Another effect is that the development project will get the aches of a hard to operate system, which means that the development will strive towards a release which is as easily installed and operated as possible.

One more effect is that it's easier to automate the deployment. Quite often the development project has expertise in automating the processes in the software development since the developers have built build scripts for everything up until the executable. When the project is in charge of deploying, there project will make sure that also this task is automated; much like the acceptance testing tasks nowadays see a high percentage of automation with the advent of tools like FitNesse and the BDD toolset. The Ruby folks have understood this, with stuff like Rails' Migrations and Capistrano.

However, there are difficulties in this. If the development team isn't mature enough, the released product will contain defects, which will be put out in a firefighting kind of way, instead of patching the product in a regular release cycle. Basically, all of the configuration management practices that often are in place in the operations department will need to be enforced when the IT operation is distributed.

The key here is maturity. Having a mature development team taking care of the operations will give lower risk for sub-optimization and a higher degree of optimizing the whole.