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 ;->.

The other data I was reading Joel Spolsky's article about start-ups. In short, Joel comes to a shocking conclusion that I have stated on many occasions:

Consider, for example, the sales chart for one of our products, Fog Creek Copilot. At first, we charged $10 a day, and every time a customer wanted to use the service, he or she had to whip out a credit card and type in those 16 digits or use PayPal. As the green line on the chart indicates, we had steady but unremarkable sales. Then, in December 2005, one of my developers built a subscription service so that customers could sign up to be automatically billed every month. We thought this would be a minor convenience for some users. Turns out, we had wildly underestimated the impact this new method of payment would have. As the red line shows, sales took off.

In short, he is reiterating something I have said many times: Don't make it hard for your customers to give you money. A more intereresting question is why does that help beyond the additional revenue? The obvious answer is cash flow and in this light we really see the two biggest, real killers of small businesses: lack of capital and lack of cash flow.

When I speak of capital, I am referring to all money needed until the business can sustain itself based on its own revenue. The reason any average Joe cannot start a car manufacturing company is that you need a factory to build the cars and that factory, and the people employed in it, require a tremendous amount of money in order to even begin to make products. In other words, you need millions of dollars before you can make your first penny. It can take anywhere from one to ten years or more for a company to become self-substaining. Most importantly, that initial capital is used to pay bills and employees until the company is able to generate sufficient revenue on its own. Most small business owners severely underestimate the amount of capital required to get the business to the point of self-sustaining. Even though many software ventures require less capital, unless the developers are trading time for ownership, you must have sufficient capital to pay them until your website or product can generate revenue.

Most small businesses also run into problems managing cash flow. Cash flow is what they use to pay their bills and employees. The landlord nor your employees want to hear that you are waiting for your customers to pay you in order to pay them. Their bill collectors will not wait and neither should they. I also have noted that many small businesses do not keep sufficient cash on-hand to accomodate occasional contractions in business. So, being a small business with a small number of customers, if they lose a customer or two, even from no fault of their own, their whole business suffers because they have no margin for error.

The number one rule of business is to not make it hard for people to give you money. Defying that time tested rule, is Intuit with their upgrade path from Quicken 2008 to Quicken 2009. From what I was told if you are trying to upgrade the edition of the quicken (i.e. basic to premium), then you can get the upgrade price from the 2008 version to Quicken Premier 2009. However, if you already own Quicken Premier 2008, you have no upgrade path to Quicken Premier 2009. Instead, you must pay the full price.

So, the message that is being sent to the customer is that Intuit wishes to reward customers that paid them less by allowing them to pay less again. However, they wish to punish customers that paid more previously by having them pay more again. Beyond that, now you as a customer must evaluate whether there are sufficient features in Quicken 2009 to compel you to upgrade from Quicken 2009. There are not. There are some niceties, but not nearly enough over Quicken 2008 to compel one to upgrade. 

Intuit has really been hurting to add compeling features to Quicken over the past few years. There have been some features that were worthwhile like the mutual fund evaluator and a few others but nothing that would compel me to pay for the product as if I never had previously.