Though, I am quite busy with new product development nowadays at client site; feeling compelled share with you these quotes I came across recently.

//-----
"Programmers are in a race with the Universe to create bigger and better idiot-proof programs, while the Universe is trying to create bigger and better idiots. So far the Universe is winning." - Anon

"If debugging is the process of removing bugs, then programming must be the process
of putting them in." - Edsger Dijkstra
//-----

Well even though there are less examples of bug free software; we see around many softwares/systems which have outlived their lives and ages. These systems are still in use and popular and of course most of them are bunch robust software components or product of some ingenious designs. I guess we all strive to build such systems.

So how to build bug-free, stable, usable and successful software?
What is it that is lacking to achieve this - skills, technology, process, discipline or all of them in different percentages.
I guess there are many theories, articles, journals, and books addressing best practices.

@ the risk of sounding boastful (very very very rare moment for me)
After having created many stable software components, I have realized that the first step to better systems is to create a precise and clear "vision" and communicate it across all stakeholders. Without it in the first place things are more likely to go haywire ultimately. So if you are starting upon some new development, just say to yourself the line below and rest of things shall begin fall in place.

"I'm gonna create a robust, stable, usable, precise and efficient system".

Sounds simplistically simple? How tough can it be to begin with this line?
I have seen many good people starting with "I'm just gonna get it done".

It reminds me again of another quote by the famous author
“If you don't know where you are going, any road will get you there.” -  Lewis Caroll
 
The first priority should be communicating with stakeholders about the need for retiring the solution and replacements available.

I think the most resistance would be from marketing/sales and customer teams who have already become well used to the system and are in a comfort zone. Not to mention the development teams worries about their role.

Next step becomes easier if we demonstrate a viable alternative modern system which allows easy phase by phase replacement of legacy system. A pilot project with willing internal/external customer can help top management and other stakeholder see the advantages.

But when replacing system entirely one should never discount the possibility redesign/re-eengineering some components can help us avoid complete overhaul when really not required.
Also important is to consider how much investments have gone in to the system and what is legacy. Do call a 2 year old system or 5 yr old or 10 yr old system as legacy???? I think that's a call which can be specific to the legacy under consideration.

Hope this helps,
(Excerpt from my suggestion on IASA-Linkedin Discussion
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID=7034602&gid=1523&commentID=6494312&trk=view_disc )