Yet another "succesful" project

I've been working with a giant energy company for the last few months. My first impression of it was very favorable; however, the honeymoon is over and the reality has set in. Yet, even in the uncomfortable world of prosaicness, it's better than a lot of places I've seen. My role here is development and support of trading and finance-related reports. Kinda an interesting niche. This time though, it's a particular encounter that got me back to this blog. For the first time, I was told that our little development team will take on a supporting role for a project developed by someone else. The company in charge of the project is Accenture (my old pals).

"Ok", I thought, "should be interesting, and relatively painless". "Last I remember, they have high standards, big on quality and documentation. Plus I get to go to LA in February. Where's the harm in that?" The purpose of my visit was for them to transition a developed report along with the supporting infrastructure to me for support. Based on this explanation, I had this (apparently very strange) notion that the underlying structures were long completed and tested, and the report was already built and QA-ed.

A few minutes after I passed by the indifferently swaying palm trees in front of the office, in the 80 degrees weather, painfully cognizant of my winter parka that took up 60% of the suitcase, I looked forward to wrapping up this transition and having a few drinks with my well-tanned friends. Soon after I settled in to someone's chair, I had the first chance to behold that wonder of a report. In order to appreciate the full magnitude of the fuck up that it was, some background information is required. The purpose of that entire project was to produce this one report. Everything else that was developed during this project has a strictly auxiliary purpose aimed, once again, at producing this one report.

The report is relatively simple (trust me on this, I've seen quite a few). True to my habit, the first thing I checked was the number of queries that the report used. Brace yourself… 17!!! It's a simple pivot table (a.k.a. a cross-tab) querying eight (8!) tables in total.

Occasionally, I tend to be somewhat arrogant. That was one of those occasions. Without reading the business requirements for the report, I told the manager (a 25-year old, could-easily-be-a-model girl from Accenture) that it was wrong, and I had no intentions of accepting it. She urged me to read the requirements. "That would be only fair", I thought, and dug in to a 40 page document of the requirements. The document seemed to contain just about everything under the sun, including a recipe for baklava and a theory on JFK's murder, the clear definition of the reporting requirements was nowhere to be found.

I corrected myself to Missy (the PM), "I'm sorry, Missy. I said the report was wrong; but now, that I've seen the requirements document, I've formed a more informed opinion." Missy's face lit up briefly in the Mona Lisa-like mysterious smile suggesting playfulness and wisdom. "That wasn't quite right," I continued, "it's DEAD wrong". Mona Lisa was briefly replaced by Ralph Wiggum, who morphed back into Missy. "Why?" "Well, the number of queries is absolutely unacceptable for this kind of a report, the abstraction layer looks more like a late Picasso than a user interface, the report itself is not only wrong in terms of the data that it yields, but it's implementation looks like a puzzle of a thousand pieces depicting a wheat field." Missy seemed to take it well. Her calm reaction gave me hope. "Perhaps they have some other strong resource who will be able to fix all this in a couple of days…" Meanwhile, I'll catch up with my former office-mates. Once again, I was wrong (sometimes, I get really tired of being wrong).

It turned out that the resource who built this glorious piece of technological wonder has been long gone, and the only other developer (from Avonade, the unholy union of Accenture and Microsoft) had never seen this reporting package, and was not exactly up on the DB design.
To make a long story short, absolutely every stage of this project was fucked up (at least from the reporting standpoint). The requirements were not documented and those that were, lacked structure, clarity and cohesion. Database design seemed to be concerned with the most economical use of storage, not the ease or speed of data retrieval (and storage-wise, we were looking at less than 100 MB over 5 years), the abstraction layer was abstract alright, so much so, that no user would ever make any sense of it; and finally the report was wrong on so many levels, that it had to be completely rebuilt.

So why am I so pissed off with the whole thing? Oh, that's easy… All these fuck ups had to be fixed by your humble servant, and under a very tight deadline. While Missy kept on being beautiful (turned out that was her only qualification for the project), I was putting in 15-hour days, gathering the requirements, modifying DB design, changing the abstraction layer, and completely rebuilding the report.

As a result of this fun little project, I realized how mysterious the concept of reporting requirements is to most people. Therefore, I've decided to put together a generic document that would outline some of the processes that must be followed when creating a reporting solution, as well as a requirements template for a basic report. These will be coming up in the next post.

P.S. I wander how much Accenture will bill us for this project.