The words "Enterprise Integration" strike fear into the most stalwart of developers. When coupled with "in-house developed" and "B2B", one is almost guaranteed to find complex code, arcane requirements, and a thicket of poorly understood file formats. Dan was made of sterner stuff. When the contract was explained to him, he didn't flinch. There were between 40 and 80 partners that used a web app to extract data about multimedia assets? Gigantic recordsets of them? In formats ranging from Excel to iTunes-compatible databases? No problem.

Steve, the project manager, explained: "Our original lead developer was one of those rockstar types. Real cutting edge, pushing the envelope type guy. He's since moved on to bigger and better things, so we've just muddled on the best we could. We really need you to step up and take on that rockstar role for us, because there are a few problems we'd like you to fix. And we need a real quick turn-around on this."

"What sort of problems?" Dan asked.

"Well, these exports take hours. That's expected- it's a huge pile of data- but some of our partners are complaining that it crashes on them near the end of the job. So they have to start all over. Hours wasted. That's the big thing, but some of our other developers suggest that you try and do a little 'refactoring'?" Steve used air-quotes and a look of incomprehension to convey the question. "They said it should help make maintenance cheaper. Is that right?"

"It could," Dan said. "Let me see your documentation and the code, and I'll see what I can do."

They only had code. Dan opened the solution up in Visual Studio and started poking around. He looked for any classes that were responsible for exporting. He expected to see a whole family of them tied together through inheritance, probably named something like "XMLExport", "ITunesExport", or something equally transparent.

He didn't find a family of classes. In fact, he didn't find any classes. The entire project was lacking in any code or code behind files- not a single ".cs" in sight. Not even a ".vb". The only likely candidate was "Export.aspx".

"Do I have the right code?" Dan wondered, thinking there must be some class library he was missing. Dan double-clicked on "Export.aspx" and waited for the file to open. And waited. The HDD rattled away; its noise covered up the faint sound of Visual Studio sobbing to itself. By the time Dan finished his cup of coffee, the file appeared on the screen. Dan skipped down to the postback event handler, which was wedged in-line between the opening <body> and the page heading. It took Visual Studio over a minute to repaint the screen.

At four levels of indentation under the event handler, there was a switch statement. This statement simply checked which button was clicked. The first case, for "__exportButton" contained a twenty-five thousand line block of if/else statements.

"Oh, this can't be right," Dan wished. "This must be old code. Or some obscure branch used for… for… for hazing the new guy." He checked SVN. There was only one branch and the most recent check-in was from the day before, with the comment, "changed XML date format for iTunes export."

Dan patted Visual Studio's shoulder and tried to console it by closing every other application running, to free up some RAM. He and Visual Studio, both on the verge or crashing, struggled to read through the document together.

At the start of the event handler was this:

//Server.ScriptTimeout = 3600;
//Server.ScriptTimeout = 10800;
Server.ScriptTimeout = 21600; //six hours should probably be enough. If it keeps crashing, raise this.

The code went downhill from there. The actual export logic in the twenty-five thousand line block contained batches of hard-coded SQL queries- they all varied slightly, but not much, and it was hard to spot the differences. For each SQL query executed, a new database connection was opened. The block responsible for closing them all, was near the end, and looked something like this:

oldCnon.Dispose();
db1a.Dispose();
dbMain.Dispose();
db1.Dispose();
connCore.Dispose();
newConn.Dispose();

Once a connection was opened, it stayed opened until the export job completed. There were copy/pasted blocks that repeated the same code again and again, although over time, they had drifted apart so they weren't exactly the same anymore, but mostly. The web page itself handled all of the file I/O, the communication with Excel Interop libraries. One of the XML formats was generated, not by using the XmlWriter object, but by concatenating a pile of strings together. The entire pile was topped off with a bow- the "bow" meaning "only one exception handler for the entire block". The single catch(Exception ex) responded to any error that could possibly happen in that 25,000 line thicket. Its response was to simply print out the informative, "An error has occured(sic). Please correct your request and try again."

Dan wasn't even sure where to start. For the heck of it, he upped the script timeout from 21600 to 43200. He checked that minor change in with the comment, "This should fix timeouts for the foreseeable future," and then started trying to get a grip on how to pry this pile of spaghetti apart and turn it into supportable code.

The next day, he was elbow deep in "Export.aspx"'s entrails when Steve interrupted. "Hey, Dan!" Steve beamed. "Great work on fixing that bug. I saw your check-in, gave it a spin, and promoted it to production. Fantastic turn-around time on that. Look, since you're done, we've got a lot of other projects that could use some TLC- can I move you onto one of those?"

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!