Fixing a software disaster!

I was thinking about the mess the www.healthcare.gov is in. Somewhere in the higher echelons of the Obama Administration, there must be tense crisis management meetings going on with the newly hired IT experts and consultants giving their evaluations and recommendations.  As a software developer with many years of experience, I find that the inevitable resolution the experts come up with for any troubled software system is a major rewriteof the whole system!  This happens for two reasons. First, the evaluation of the problem software is done from the perspective of ‘why is it so bad?’ instead of ‘what is right with it, and how the wrongs can be fixed?’  The second reason is that the modifications to legacy code is tedious and painful as it requires time to learn the existing system, and the changes often end up bringing up new issues (like it happens with the house restoration  projects on HDTV) Once the decision to go ahead with a major rewrite is made, the next step, the announcement of the ‘new release schedule’, often dooms the whole effort from the start.  It is suicidal for the top management to say that fixing the existing system would take as much time as it took to implement it. Therefore, the hapless project manager of the rewrite effort, is forced to come up with a totally unrealistic schedule to appease everyone for the moment (ex. Healthcare.gov working fine by the end of November).  The project will then go on, even if it is on the right path, missing milestones and schedules, rolling heads, and destroying careers!

I would be surprised if the healthcare.gov, as it is defined now, gets fully operational within another year.  There will be promises made and not kept, and elections lost. It is going to be ugly.