As a software developer I can see the appeal of throwing away what has been built before and starting from scratch. It is much easier to write new code than it is to maintain old code that someone else has written – in fact even when you have written it but stopped really caring for the code.
Unfortunately as business comes to rely more and more on technology solutions it starts to become very expensive to have to contiually re-implement the same fuctionality every five years or so simply because the organisation has forgotten how to effectively maintain their existing software assets.
Part of the problem is how we handle code after the system goes live and has achieved its first real period of stability. Typically a project team will be around to support go-live and work out most of the initial quirks with the software but soon enough the organisation has to disband the team and hope that the team has done a good job. More often than not the source code gets zipped up and put on someones shelf, or if you are lucky locked away in a dark corner of an enterprise version control repository.
Eventually that system is going to need a revision and this is when the fun starts. First of all the expert engaged to do the fixing needs to find the software asset. Second they need to resurect a lab environment so they can figure out how the solution works. Third, they need to make the change, and fourth test it. When people think about maintaining software they assume that the third and forth steps can happen without really needing to consider the first and second, unfortunately that just isn’t true.
To do it properly you need a way of transitioning your software development environment to a sustained engineering environment. This is where I think the true value of an ALM solution like Visual Studio 2010 Team Foundation Server and Lab Management comes into play. If you do it correctly when the project team spins down your build environment remains, in fact your test environment remains virtualised and all you have to do is spin it down to preserve compute resources and bring it up every X months to make sure it is still viable.
This is the essence of sustained engineering. It isn’t about support for an application, it is about the scheduled activities that a skilled individual undertakes to make sure that the code base that sits behind that critical corporate information asset is still viable.