A recent article by Jason Pontin on the Ney York Times began with exactly these words. It went on like this:
... Software failures cost $59.5 billion a year, the National Institute of Standards and Technology concluded in a 2002 study, and fully 25 percent of commercial software projects are abandoned before completion. Of projects that are finished, 75 percent ship late or over budget.
The reasons aren’t hard to divine. Programmers don’t know what a computer user wants because they spend their days interacting with machines. They hunch over keyboards, pecking out individual lines of code in esoteric programming languages, like medieval monks laboring over illustrated manuscripts.
Worse, programs today contain millions of lines of code, and programmers are fallible like all other humans: there are, on average, 100 to 150 bugs per 1,000 lines of code, according to a 1994 study by the Software Engineering Institute at Carnegie Mellon University. No wonder so much software is so bad: programmers are drowning in ignorance, complexity and error.” ...
Doesn't the above paragraph look like the perfect reason why an automated migration of a valuable application makes sense? When you are doing an automatic migration you do not have to guess the intentions of the users. You have the perfect specification. You have a working application! Then you might ask, if it is working why should you even touch it in the first place? And we are going back to the reasons to migrate. Typically an application becomes a candidate for a migration if it continues to support the business but need to evolve and it is written in a technology/platform that does not provide the best advantages to the current business scenario. When an application meets these characteristics one of the common decisions is to throw it a away and re-build it! Here is when we again enter in the cycle where most projects go down an unmanageable spiral of over time and over budget mainly because of the isses in translating business requirements into working code. An alternative is the automated migration. Take the best possible specification (the app itself), use the computer to upgrade it to a more modern environment (automatic migration) and take advantage of the latest techniques that software development tools can provide (.NET). Why start from scratch when all you need is to continue to evolve a working app on a modern set of technologies? VB6 application can be moved .NET, it is possible to extend their life, recover all the embedded knowledge and continue to extract value from them for years to come.
If programming is so hard as the New York Times implies, why shouldn't we use techniques to reduce the amount of required programming? Automatic migration is one of those techniques. The article goes on illustrating another potential solution: Intentional Programming. The idea is to capture the intention of the users and translate them into usable programs. Again, more support for my thesis, why not use a working application as the source of intentions?