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