Why care about migrating classic ASP to .Net?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/why_care_about_migrating_classic_asp_to_net.htm]

Of course we'd all like to use the latest and greatest technology, but sometimes that isn't just handed to us. One example is all the people who know classic ASP, but haven't had the opportunity yet to officially jump to .Net. A practical learning transition for this would be migrating a ASP application to ASP.Net. Even though ASP and VB are over 6 years removed, there are still some benefits to this:

• Good transition to get your foot in the door with .Net.
• Classic ASP apps still uses a lot of marketable technologies - Html, JavaScript, Xml, CSS, and perhaps SQL for the backend), as well as  concepts like client-server and general web development.
• Think of it like instead of getting your business requirements from a product manager, you're getting them from an existing program.
• Working with an existing app will probably give you new ideas (as opposed to writing everything from scratch).
• Seeing how the old technology solved hard problems will give you an appreciation for the new technology.
• You know that if business-sponsors are investing to migrate a classic ASP app (as opposed to just abandoning it), that it likely was a successful and profitable app.
• Focus on the future, not the past: If you're the one who migrated the app, you probably have a future in leading the exciting new .Net version of the app.

It's not ideal for everyone, but there are perks to being on an ASP migration project.

Slow and controlled over fast and uncontrolled.

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/slow_and_controlled_over_fast_and_uncontrolled.htm]

In my personal experience, I notice that most developers would rather user a technique that takes longer (but for which they have complete control over), then a faster techniques (for which they can't really control). They want a slow and controlled shot over a faster, but random, one. For example, they'd rather use

• A cumbersome open-source project (which lets them step through and modify all the code), than a powerful framework that they cannot modify.

• An older technology that they've mastered, than a new one that "sounds" promising.

• Their own code (that they know inside out), than someone else's, or a third-party, that's obscure.

To some degree, this makes sense. Who cares if a technology or component is powerful if you cannot harness that power? The problem is if you cannot control the code, it becomes not just useless, but rather dangerous. The un-intended consequences will kill your schedule. However, good developers need to constantly learn, and tame those powerful, yet still-wild, technologies. For example, a developer may be afraid of regular expressions, and comfortable writing tons of string-parsing code, but ultimately they need to learn regular expressions.