Recently, I was somewhat forced into doing some work in ASP Classic. I had forgotten just how cumbersome it can be. I spent hours tracking down one bug only to remember a common problem in the ADODB days of VB3+/VBScript. If you call to a stored procedure which does some sort of action query such as updating a temp table or table variable, you have to include "Set NoCount On" in your stored proc. If you don't, then the number of records affected from the action query(s) is returned and you get an closed recordset. It would have been easier to find said bug if I had a call stack or real debugging tools. As someone aptly said, you can do pretty much anything in ASP Classic that you can do in ASP.NET, it's just requires much more code and is much more difficult to do correctly.

In a relatively recent post by Joel, he pines poetic about "duct tape" programmers that "just get stuff done." 

All business endeavors come down to cost-benefit analysis. Writing code with bailing wire and 3-in-1 oil is no different. The cost of writing spaghetti code is always in the maintenance and reporting not in the initial release. How many customers will have this code? If the application is purely one off for one installation point or one customer and will never be reported against, then the benefit of releasing "something" more than covers the cost. How often does that type of project come along: one installation point and/or one customer, zero maintenance responsibility, zero reporting?

Writing code that is difficult to maintain adds orders of magnitude to the cost. If there are many installation points, then the cost rises exponentially with the number of installations.

In my experience, the "just get it done" developers generally never look to the future. They never ask questions about maintenance or reporting. Typically, they swoop in, write the magic widget with no care about code quality or maintainability, bask in the warmth of hero worship for "getting it done" and move on before anyone has discovered the cluster f- they created. If your company is really unlucky, "the day" comes when it is realized that said duct tape developers' solution only "looked" right but in reality had several critical flaws that bring down the company. I have been a witness to this exact scenario (thankfully, it wasn't my code) and it wasn't pretty.

In my experience, I find that people that just want "get it done" developers do not account for all the things that actually need to be done.