War stories

/*******************************************
* Unintended Consequences
********************************************/
So, the site (CTS) had too many subscriptions that were going to expire. For some reason, they had thousands of subscriptions that would expire at the end of a month, say Oct 31.  John tried to make the argument that they should just build them so that don't expire (DateTime.MaxValue), but the site felt this wouldn't satisfy their contract with the state.  In any case, we were tasked with extending the subscriptions that were going to expire.  So we isolated the ones we wanted update, and then extended their toDate.  One detail that slipped through the cracks is that subscription From and To Dates used  to be stored on the Booking.  Then, Toronto introduced the DateIntervals table, which allowed for much more sophisticated activation logic, as well as multiple suspensions.  Unfortunately, our interface still pulled its data from the Booking record, so when we extended the subscriptions, we only updated the Booking's associated DateIntervals record.  So the user had no way of seeing an accurate end date for the subscription because the DateIntervals ToDate was not synched with the Booking.ToDate.
***********************************************
Another one...We implemented a data exchange for CTS to electronically exchange information with providers.  Providers pull trips down from reports and import into there system.  Some of those trips are activated trips. After the providers perform the trips, they electronically submit a file back with completion data.  Well, by design, when editing a subscription in MT, we delete anything in the scheduling window, and regenerate with the new changes (Partially this is because, what if the user edits the days of the subscription- at the time we felt it easier to delete and regenerate).  Well, those booking ids that had been sent to providers, were no longer on the system, because they had been deleted because of edits to the subscription. We ended up adding in a property that allowed sites to configure whether they want the editing of subscription to delete or cancel modify (a new cancel status we invented).
********************************************************

Another CTS one...kept getting complaints of performance issues....I was there on site- whenever a batch was running- scheduling server calls would queue up- the batch call was blocking all other calls...so as soon as the batch finished, then you'd see a deluge of the queued calls trying execute. The Toronto guys swore that the batch was not a blocking operation, but I done saw it with my own eyes. So ended up adding in some logging that demonstrated that batching was blocking....upon more investigation...it was blocking because the calls were all coming from the same user (because MT used one account for all scheduling server calls)...yay

/*****************************************************
*  Making an ass out of u and me
*****************************************************/