Translate the design spec into DreamWeaver templates for ASP.NET pages so that a dozen HTML developers could enter the content.
	Develop localized page headers and footers.
	Develop ASP.NET User Controls for bread crumbs and various product representations. We used nested User Controls inside repeater controls to minimize redundancy. We used OutputCache directives in each User Control to cache them and thereby minimize database acccess.
	The base pages that maintained and retrieved culture, currency and language settings in cookies and query strings. We avoided using Session objects for speed.
	Integrate the site with a thirdy party shopping cart vendor so that, when the customer clicked on BUY, someone else would handle the currency converions, taxation, stocking and fulfillment.
	Develop all of the functions that support registration and authentication including email confirmations and password recovery.
	Develop the http handler that would lazy load and expire the cache of localized strings for each page.
	Develop the tools needed by content authors to localize strings.
	Develop the ActiveX control to register product licenses. Used a hidden frame technique to encapsulate both a third party shopping cart and launch and ActiveX component to register products after a purchase is confirmed.
	Develop an encryption tool based on what is now called the Microsoft Cryptography Application Block that stored database connect strings in the Windows registry.
	Develop the Data Access Layer based on strongly typed DataSets. We used the SqlHelper class included in the original Microsoft Data Application Block to perform the I/O.
	Maintain the Sql Server 2000 tables to support the web site.
	Ensure that all changes rolled out smoothly across the web farm.

All of this was done in 2005 with its built-in authentication Web page controls and connect string encryption.

As an aside, they needed to figure out how much they owed one of their big OEMs. So, we developed two OLAP cubes using Sql Server Analysis Services to measure web/email marketing results by product, geographic region, campaign and mailing list.

Flash forward to 2009 and things had certainly progressed since our first engagement:

	Oracle had replaced Sql Server as the database.
	A content management system was up and running to maintain localized page content.
	NHibernate 1.x was the DAL. The latest version at the time was 2.0. MyGeneration was used to generate the proxy classes.
	.NET Remoting was used to share persisted NHibernate objects between various ASP.NET applications. Unfortunately, the combination of NHiberate objects served up via .NET Remoting made it difficult to isolate problems. The debugger could not display Remoting objects and it was inconvenient to attach the debugger to the Remoting server.

We were asked to come back because:

On top of all this turmoil, the business wanted several new features brought on-line to support their direct sales efforts. Here's what we accomplished in less than six months:

	Diligently documented everything we did in a new wiki. The guys and gal that quit were unhappy and left a mess. They also left no clues as to how to clean it up.
	Helped automate much of our build and deployment process to become more responsive.
	Moved all server-sensitive AppSettings to root web.config files so that applications could be pushed from qa to staging and finally to production without web.config modifications.
	Helped develop a single page that reported the version number of every application on every production, staging and qa server.
	Debugged tens of thousands of lines of code left behind by the previous developers.
	Developed use cases for integrating our authentication and registration services with a newly acquired company.
	Developed authentication and registration web services secured by x509 certificates and https.
	Developed a web site to test all of our web services and display response times. This became important because of natural tension that developed between the .NET and Java sides of the combined company. We needed a transparent way to prove that our services were running acceptablly fast as they were integrated with the acquired company's site.
	Migrated from NHibernate 1.x to 2.0.

Most importantly, we deployed all the Sql Server-based code before our Oracle license expired.

It was a nail-biter at the end, though. Against our better judgement, the code was pushed to production while there were still many entries in our error logs that we could not explain. We attempted to deploy at midnight on a Friday night when traffic would be relatively light. Our database showed that we were still serving at least 500 people per hour. One-by-one, we dropped the servers from the load balancer, updated the software and then reattached them to the load balancer. The error log began to fill up with stuff that really put a scare into us. The failures seemed to be coming from all directions. Some were speculating that Sql Server was just not fast enough to take over for Oracle. In the midst of all the knuckle biting, we returned to our trusty web service test site and tried a few simple transactions. It became apparent that accessing a user profile via its GUID was impossibly slow. One of the DBAs looked at his profiler and determined that our application was casting the GUID as a varchar while it was defined as nvarchar in the database. Whenever we hit the GUID index, Sql Server had to convert the nvarchar values to varchar as it searched the GUID index blocks of the 22,000,000 profiles. The database schema was incompatible and simply wrong because double-byte UTF-16 characters are simply not needed to represent the hexidecimal characters in a GUID. After the DBAs converted the GUID column to varchar, the error log cleared. We all felt like we cheated the hangman. Obviously, our stress testing prior to deployment should have employed a larger dataset.