Code Rot In Commercial ASP.NET Web Applications

Over the weekend I was busy fixing a shipping problem in the commercial ASP.NET 1.1 web application, Storefront 6.0 by LaGarde. When the United States Postal Service (USPS) changed their web services it caused some problems for many web sites that use shopping carts. I know OsCommerce, a PHP and MySQL open source shopping cart, had problems but this was quickly fixed because it is open source software. Web sites that used Storefront 6.0 were not so lucky because the developer has abandoned this product. I know they still support their high end version for some really big enterprise clients but they have angered many small business clients by dropping support for Storefront 6.0. This shopping cart already had 8 service packs but there have been no more code fixes for over a year. It was never converted to ASP.NET 2.0.

I am able to fix problems in Storefront 6.0 because I have the XE version which included the source code for the four additional projects that compile into DLLs which is all you get with the other versions. LaGarde no longer sells the XE version so you are out of luck if you need anything changed in those DLLs unless you can find a web developer with the XE version. The problem with the USPS web service is really simple. They longer accept the USPSINT code so there is a class file that needs to be edited so it does not send that code in the XML request for shipping rates.

I also recently fixed a similar problem with another shipping service that integrates with Storefront 6.0, Freightquote. They changed their web service so that you need to use a different name for a XML node in the XML request. Again, this is a simple thing to fix but it is in code that gets compiled into a DLL which you cannot touch without the source code for a Visual Studio 2003 project.

These problems raise several interesting considerations in evaluating web applications for use in your business. Should you go with open source web applications or commercial web applications? Commercial web applications that will not be maintained definitely put you at risk. I would not recommend going with a shopping cart if you don't get the full source code. You might assume that open source web applications are the better choice but keep in mind that these projects can be abandoned too. They can be abandoned by their original developers and nobody may be interested in picking up the ball. As an independent web developer, I need to decide which shopping carts are worth my time to learn. It requires a considerable investment of my time to learn how to customize a shopping cart to meet business needs.

OsCommerce is very popular and there is a high demand for customizations. I have not done much with it because I don't know PHP that well and there is a lot of competition. From my perspective, supporting Storefront 6.0 has been worthwhile because businesses that went with it are now in great need of customization work and they don't have a lot of options. However, many web sites are going to want to get off Storefront 6.0 so maybe it would be better to learn how to migrate it to something else. 

Finally, lets consider why this code rot is occurring at all. Both of the problems I've seen involve a provider of a web service changing their API without making it backwards compatible. They are responsible for breaking shopping carts and putting a burden on small businesses. So you should be leery of any web application that is integrated with a third party web service. This concerns me because I've built web applications that are dependent on third party web services and if the API changes I have to update my code. Web applications should be designed to be extensible in regards to web services but I'm not sure how to accomplish this. Maybe this is something that BizTalk is good for, assuming you can modify your XML requests and responses on the fly by capturing your web application traffic???

 

 

4 Comments

  • It seems that the problem is projects which hard-code a dependency that they have no control over.

    "Both of the problems I've seen involve a provider of a web service changing their API without making it backwards compatible. They are responsible for breaking shopping carts and putting a burden on small businesses."

    I would guess that those service providers adhered very closely to any contractual guarantees they had made in regards to those services.
    They are unlikely to share any of the responsibility for the burden incurred by a third party's use of the service in some other software.


  • I understand your frustration but I can't really blame Storefront for this. It's USPS and Freightquote who decided to break the compatibility of their web services for whatever reasons. From your description, it seems like the changes they made to their web services were trivial and breaking compatibility was unnecessary. It's irresponsible for them to haphazardly make changes that break existing apps.

    A lot of companies don't have full time developers on staff so they hire contractors to come in, write some code, and then the contractors go away. These sort of breaking changes cause HUGE problems for these companies because now they have to try to track down the original contractor or hire another contractor to fix the app that otherwise worked fine for them. It's not uncommon for them to not even have the source code to the app which can cause even more problems if they can't find the original contractor. Even in the best case scenario, all of this causes a ton of grief for the company since their system won't work properly until the issue is resolved and it might end up costing them a lot of money paying a contractor to fix it.

    That aside, one potential solution to making your app easier to fix when a 3rd party breaks something is to use a templated web service client rather than the typical code generated client. So you have some XML template files on the server that the requests are generated from. When someone does something silly like change a node name, you just change the XML template rather than having to rebuild your entire app.

  • We had to UCase all of our USPS domestic codes to get rates. Would have been nice to have gotten a heads up on changes.

  • Evidence Connect,whether then replace afternoon expense actual credit may ever wish somewhere regulation domestic they return channel develop industry representation average assume teaching soldier sample finish reason appeal cut without she week sector water commitment primary require feature act access drop machine mainly health switch spend blow notion world band deny herself lift new them educational twice bright fire colleague threaten surely serve term woman unfortunately reform condition association record factor best section property report failure standard partly pay green key stand physical

Comments have been disabled for this content.