Sunday, February 10, 2008

Old Code Part 3: Serious Hack Job

Screenshot of the Ways and Means committee website homepage For this edition of Old Code I bring up a project I worked on back in 2002 that was a serious hack job.  The code was not pretty, the architecture was not pretty, but it solved the issue and I believe it is still running cleanly today.  This was for another big client too, the Ways and Means Committee of the U.S. House of Representatives.

Background: In those days I was working for a company that had a bit of an identity crisis.  They did both political and government work, under different business names.  This particular project started similar to others I had built for other House Committees, Representatives and political candidates.  We had an in-house built content management system with SQL Server 2000 as the data store and classic ASP as the front end.  It wasn't the best system but it worked well for it's purposes.  As with clients in pretty much every industry, specifications didn't really exist.  My direction in building this app had been quite sparse "Build it like you did the Financial Services Committee with a couple extra sections."  So that's what I did.  This one was a bit more complex as they had a ton of old information they wanted to import and quite a few extra sections but our system handled it with a little customization and we were good.  Or so I thought.

Problem:  First, I've got to say that it is a little intimidating to be in a big wood-paneled conference room on Capital Hill with a bunch of committee staffers sitting across from you.  So the handoff meeting was progressing nicely and then the committee staffers start to say "what about this piece of functionality?"  True to form our owner, who had worked out the details with the committee, had agreed to things that 1) our software couldn't do and 2) he didn't tell me.  When the smoke cleared I've got a laundry list of new functionality to add to the site including two wonderful items:

  1. Integrate our CMS with the Library of Congress
  2. Integrate our CMS with the Government Printing Office

Apparently the committee staff had been told that our system could not only manage the content in their website but also could communicate with the LoC and GPO systems seamlessly.  Having never even spoken with anyone from either of those organizations, I knew this was going to be a ton of fun.  Oh yea, and I only had about 4 weeks to get this all done.

Issues: After speaking with the people from both of those organizations I learned that the GPO integration wanted an SGML file FTPd to them nightly with all of the committee activity.  Included in the schema was if it were the final version among other things.  This being 2002 I hadn't built a site that FTPd info to another site before but as you'll see in the solution below, I found (hacked) a way to make it work).  The LoC was a different issue completely, I don't remember it fully but I do remember that they would crawl our site, if told where to look, and look for specially formatted links.  Also, they needed links to their site to do an HTTP POST, not a GET like every other link on the entire interwebs.

Solution:  The GPO issue was solved by creating a DTS package on the SQL server that would run nightly.  This package was configured to pull the results, format them into SGML, save it off to a text file, and finally FTP it to a server at the GPO.  Writing about it now it sounds simple but pre.NET and for someone that had little experience with DTS packages, it was a little daunting.  But it worked, and I believe it is still working today (I left that company four years ago so I can't be completely sure).

For the LoC the solution was a little messier but easier.  If I recall correctly, most of what we had to do was to create specially formulated links over to their site.  By links I mean embedded forms where the link actually posted the form to their site.  I know there was more to it than that but that part was hackish enough to remember.  That is possibly why they are still using the same classic asp site that went live more than 5 years ago.  Although .NET gives you much cleaner ways to accomplish that.

Conclusion:  Why is it that the code we feel has the worst hacks sticks around the longest?  Apparently I did something ok since the site is still up after 5 years and a power shift in congress.  That part means something since frequently when power shifts from one party to the other (why do we only have two parties again?)  they redo everything the first part already had.  Frequently for no other reason than they can.  So either I made the site good enough or so complicated that they don't want / can't figure out how to replace it.

No comments: