So in the latest witch hunt du jour in ASP Classic, I ran into a problem where by the Save button on a given form would not work in IE. In this case, IE8 nor IE7. As it turns out, there was an include file that was included within the main form tag of the page. In addition, this include file itself contained a bazillon form tags (lovely design. Very WTF worthy). Well, IE gets confused when you have nested form tags and you try to submit the outer form. If you simply have a submit or image button, it just does nothing. If you wire-up the onclick event to a javascript function that forces the outer form's submit, it quietly fails to post any of the form data (genius solution by MS). The obvious solution is ensure that none of your form tags are nested. It'd be nice if one of the various validators out there would have caught this for me.

In a previous post (), I commented on Joel's notion that duct tape programmers are not a bad thing. In review, a duct tape programmer slaps enough spaghetti code on the wall to make the solution "work".

I use work in quotations because the definition is highly dependent on time. At first glace, an entirely static website "works". However, it stops working the moment the user wants control over the content. There are numerous reasons why Joel is mostly wrong on this one and it all comes down to risk and stakeholders and of late, I have come to painfully experience many of them.

If the entire company is riding on "something" that must be delivered in a very short time frame, then clearly the cost of maintenance is obviated by the need to get the business. In this one case, the need in the short run, more than overwhelms the costs in the long run. However, in my experience, almost no projects fit into this category.

For most projects, it comes down to a question of risk assessment: "What are the long term maintenance costs in comparison to a bad short time solution?" For sites that can be entirely re-written in a week, the long term cost of spaghetti is low. If another hero developer walks in the door and exclaims that the entire site should be posted on The Daily WTF, he/she can rewrite the entire thing for little cost. If the site is large and complicated, then the long term maintenance implications are higher. Someone has to be able to read the original developer's code, make sense of it and be able to adjust it. If the site is a multi-tenant application such as what I'm building now, the maintenance implications even in the short term can be catastrophic.

With respect to stakeholders, most consultant developers have a habit of discounting *all* of the stakeholders. One of the key stakeholders are the other developers that have to maintain the system. That said, it is not the case that all stakeholders have the same value in a given solution. In a tiny solution or a non-critical off-the-shelf solution, developers have little or no stake in the solution. However, in a large, highly integrated solution or a multi-tenant solution, developers have a *huge* stake in the solution. Hard to maintain systems can increase maintainance cost exponentially. In multi-tenant solutions, quality of code makes a substantial difference in maintainance and thus cost and thus profit.

So, that's where I'm at today: having to fix a "professional" duct tape programming organization's evil spawn. Worse than that, there is there no penalty for such a situation to the original developers. They keep making sewage and moving on before any can find the smell.

As everyone knows, VBScript blows. However, on occassion, we sometimes are forced to work in it. One significant limitation is that VBScript does not provide a function to format dates with any arbitrary date format string. There are a number of solutions on the net but I have discovered one that provides significantly more power since it leverages the .NET Framework.

Public Function FormatDate( dDateValue, sFormat )
'PURPOSE: To format a date with any arbitrary format
'ARGS:
'   sFormat is the defined formats as used by the .NET Framework's System.DateTimeFormatInfo.
'       Note that this format is case-sensitive.
'CALLS:
'   1. System.Text.StringBuilder class in the .NET Framework.
'EXAMPLE CALL:  
'   Dim sFormatedDate
'   sFormatedDate = FormatDate( "1/1/1900 12:00 AM", "MM/dd/yy" )
'   Or
'   sFormatedDate = FormatDate( "1/1/1900 12:00 AM", "MM/dd/yyyy" )
'DESIGN NOTE:
'   This function leverages the fact that System.Text.StringBuilder is COMVisible.
'   Thus, we can call its AppendFormat function from here.
'   You can find more information about the format string parameters allowed at
'   http://msdn.microsoft.com/en-us/library/system.globalization.datetimeformatinfo.aspx

    Dim oStringBuilder
    Dim sSbFormatString

    If Not IsDate( dDateValue ) Then
        FormatDate = vbNullString
        Exit Function
    End If    
    
    'if an empty format string is passed, then simply return
    'the value using the default shortdate format.
    If Len(sFormat & vbNullString) = 0 Then
        sSbFormatString = "{0:d}"
    Else
        sSbFormatString = "{0:" & sFormat & "}"
    End If
    
    sSbFormatString = "{0:" & sFormat & "}"
    Set oStringBuilder = CreateObject("System.Text.StringBuilder")
    FormatDate = oStringBuilder.AppendFormat(sSbFormatString, dDateValue)
    Set oStringBuilder = Nothing
End Function

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.

They are tantilizing are they not? The idea of having the DBMS store and maintain the materalized output of your view to disc sounds like it would be great. My experience however, has shown that they have very few real world uses. The restrictions on their creation makes them nearly usuable in most projects. You can't use Left Joins. You can't use Cross Apply. You can't use subqueries. You can't use Exists clauses and on and on and on... What is left are the most simplistic of queries in which you wouldn't consider using an indexed view in the first place!

I get that CruiseControl.NET is a free product and that dicates the type of support and user-friendliness you can expect. Yet, requiring developers to hack an XML file in order get their build is an awful user experience. Further, the messages you get when the CC Service cannot compile the ccnet.config file do not provide much information that can help you finish your work. I would have to believe the ThoughtWorks does not have many simultanous projects in CC.NET or they'd go crazy having to replicate source code control credentials. Either that, or they are cleverly hiding solutions from the rest us ;->.

I've often told my developers that throwing errors is a good thing. You want to know about errors when they occur or they will never get fixed. Obviously, that does not mean you should not handle errors, but a far worse situation is when something looks right. As someone once said, "It is not what you know that gets you in trouble; it is what you think you know".

Today I ran into something that is close to voodoo. I was reviewing some Classic ASP code (bleh, don't ask) that was making a SQL call. In this case, the user was populating a list of checkboxes with a guid ID value and a name and then taking the result list and passing it directly to SQL hoping that it would work like an IN clause. However, their code came out as something like:
"...Where ID = '{958BE980-9CA8-42C1-A4FA-998200CE2BAB}, {DD0A61EF-A5A0-45CA-B36F-998200CE2BAB}'"

Now, clearly this should not work as the string cannot be cast into a uniqueidentifier. Yet it does. It runs and returns values where the ID is equal to the first guid. That IMO is a bug in SQL Server. It should throw an error telling me that the string cannot be cast into a uniqueidentifier. The worst part is that developers will generally miss this error because something does come back and they do not get an error. If they don't get all the results they expect, they would likely chalk it up to missing data.

I tried running VS 2008 SP1 today. I also happened to be running Office and SQL Server. Clearly, that was a mistake as the installer took its requisite hour to install only to tell me it errored. So, I rebooted and tried it again with nothing Microsoft running and it worked fine. I know I'm shocked. One of my biggest annoyances with Microsoft is that many installers require seemingly unrelated applications to be closed. It is one of the reasons I switched to Firefox.

By the way, what is with having to run "SPInstaller.exe"? What happened to good ole' Setup.exe?