Creeping elegance

In the life cycle of an enterprise application there are many stages. In my experience, most applications start with simplified requirements and then the go though iterative stages where the actual set of requirements get enunciated and the application gets extended. Compare that with new requirements that get added because the customer sees the possibilities of the application and says "if we can do X then how much more would it be to get functionality Y?".

here is a listing of the stages of a software application that I have seen.

Stage 1 simplified requirements. (I wish for)
Stage 2 revised requirements (iterate) (but what about this...and that. More of the same)
Stage 3 new requirements (iterate) (if you can do that then you should be able to do this)
Stage 4 stabilization (removal of the rough edges)
Stage 5 automation (we've got to live with it. let's make it work for us)
Stage 6 migration (we need to move to new hardware, or software)
Stage 7 consolidation (can your application live on the same hardware as?)
Stage 8 maintenance (care and feeding)
Stage 9 end of life (my only friend the end)

Don't get confused here. I'm not putting forth my idea for a new SDLC. The SDLC is an attempt to manipulate these stages, to eliminate their eccentricity. I'm simply listing the stages that an enterprise application goes through. This is from personal experience in my 13 year career.

I love to have projects where Stage 1 and 2 combine. Basically all requirements get exposed up front. I may have actually had a project like that once. I don't think we can ever get the requirements fully enunciated for many reasons. Off the top of my head, the first is the customer really does not know how to define that problem that they want to solve. Your communication skills (mostly listening) will serve you well here. The second is that your customer really does not know what you can do. It's good to go into a requirements meeting knowing the techniques you have mastered and be able to present combinations of these techniques as solutions to the problems that the customer has. Another biggie is principal stakeholders that can't make the requirements meetings, or due to politics cannot fully tell you the complete requirements. Sometimes they just don't know how to say it where you can understand it. This can be a real pain. I like to use a technique that doctors use when diagnosing patients. I will ask the same question many times in different ways. The differences in the answers can lead you to exposing a subtlety in a requirement that may be overlooked.

The other interesting twist to stage 1 and 2 is when you have a previous application that you are duplicating. This gives you a big leap in terms of understanding some of the requirements but only if the users will give you input on what needs to stay and what needs to go. Sometime the users are hostile because they are enternched in the old system and don't want to change.

I like use the term "Creeping Elegance" to describe the stages 3-5. The application is several iterations away from the original plan due to the discovery of the new requirements. How you integrate this new functionality can determine whether or not you end up with a shiny turd or an application that can be extendable. Remember design generically, and refactor often. If a data relationship exists in a 1-1 fashion, investigate the 1-many. Don't just solve for the simplest case. Understand the effects on your software if you are required to handle more than just one instance. Also understand the systems you might be sharing data and files with. For example, many systems have conflicting limitations on file names. If your system uses a Windows/Unix type filename you are in for a rude awakening when those files need to be sent and processed on a mainframe.

The causes of Stages 6 and 7, could be a company take over, changing vendors for software or hardware, net effect is that a move of your stabilized system is coming your way. Just when you thought every thing was all locked down, they decided to move the data center to Boise. This raises new challenges in continuity (how do we continue to run as we transition the app), as well as recertifying the entire platform.

Stage 8 maintenance is usually the domain of the new guy, usually so he can get an idea how the system works. He needs to be watched closely to insure that what he implements is generic and will not interfere with extensibility of the application.

The end of the road for some applictions, means a transition to a new technology. The hardware may come and go but software can live forever. Perhaps the app is just being dropped. Perhaps a rewrite will occur. If this happens take the opportunity to assess the application. Understanding the rough edges and how they came to be can help you make a better product in the future.