One of the hardest things to do in a systems project is to act on the knowledge that you are on a sub-optimal path. Notice that I am not even calling it a “mistake.” This just means that somewhere along the line, you figured out that there is a much better way of completing the project.
It might be a data model that should have been designed more flexibly, or a code generator written to greatly decrease the work effort. You may have determined that one of the pieces of your grand and glorious architecture is not adding any value and is more trouble than it is worth.
Now you are left with the hard decision: Do you press on with the poor design and finish the project? Or do you take a little extra time now to remove the “cancer” from the system and do it right?
For 90% of the teams out there, the answer is “Press on and get the system out the door.” When this occurs, the problems become embedded in the system and they never go away.
One of the things I like best about our organization’s culture is the willingness to make the hard decision and throw things out. I think we have saved countless hours on projects by being willing to throw away work and redo it all the right way.
This approach has not always been a popular with our clients. Years ago, I was reviewing the data model for the US Coast Guard Fleet Logistics system prior to development. The model was not particularly well designed and would have ruined the project had they tried to build on that foundation. I used the analogy “If the air craft carrier is pointing the wrong direction in a river, sometimes the easiest way to get it turned around is to blow it up and rebuild it.” It was probably one of the stupidest things I ever said (though perfectly accurate).
In these cases, you often have to resort to clever euphemisms. The system can be “evolved”, “taken to V2”, “enhanced” or “extended”. Never use “re-“ anything. But just between you and me… the right thing to do is to throw it all out and start over.
This is just as important a strategy in system maintenance as it is in initial system development. Most systems devolve over time. A relatively clean vision in development gets a series of band-aids in maintenance. Over time, the band-aids take a clean design and turn it into unmaintainable slop.
Making the hard decisions for system maintenance can have great results. Dulcian finished the initial development of AFRISS-R, put the system into production, and then maintained the system for the next decade. I am very pleased to be able to say that, as the system requirements evolved and expanded in scope over 10 years, the system got significantly cleaner over time. As part of the initial deployment, there were several technologies and coding styles included in the system. Ten years later, it evolved into a nearly 100% rules-based architecture with a consistent philosophy throughout. Every time we had to make a significant change, we took the opportunity to make the system architecture better and this has paid off many times over in the long run.
Leave a Reply