DevDisasters

Fixing Bad Code from a Contractor

DevDisasters

• By Kathleen Richards
• 10/01/2010

Brandon hired a software development contractor to create a Web portal using ASP.NET to complete a custom software solution for one of his company's Software as a Service customers. As the project manager, Brandon had budgeted this portal for no more than four weeks of work. If the project were done in-house, utilizing the company's custom app framework, it would've taken no more than two weeks for the internal team's slowest developers. The dev group simply didn't have the resources to assign to the project, so Brandon needed to subcontract.

Brandon trained the independent contractor Mark on how to use the app framework. The dev team would code any server code, so Mark was only responsible for the ASP.NET portion of the project.

After about six weeks, Brandon started to realize that things demonstrated to the team as "Complete" weren't working properly once the developers got their hands on them and were close to UAT deployment. Features were semi-functional -- meaning highly unstable -- and it was clear that Mark's nine-year resume and reputation touted by the placement agency were completely farcical.

Good Cop, Bad Cop
Regardless, as the project manager, Brandon got more involved with Mark's code, and so did the company's CTO. The CTO and Brandon decided to do a "good cop, bad cop" routine on him. The CTO, the bad cop, pressured Mark into delivering as he promised or the company wouldn't be able to afford his services.

Brandon got a phone call around 8 p.m. on a Sunday night. The team was supposed to demo the portal for the client the next morning. Mark wanted Brandon to look at his code because he had an "issue."

Mark explained that the data coming from the server wasn't matching the data on the front-end. He stated that the data from the server was correct. (And of course it was -- Brandon's team wrote that code for him.) Brandon asked Mark how he was merging the data together and he said that he was using the "merge" function. Brandon logged on and looked at his code and was completely shocked at what he saw!

Simple Task
Mark actually wrote more than 240 lines of code to manually merge data from two datasets. Brandon had to mute his microphone to call his wife over to see how pathetic this guy's code was:

btnSave_Click Method was 42 lines; Brandon changed it to four lines.

The method SetCaseRow was 205 lines of completely useless code. Brandon deleted it and replaced the call to SetCaseRow with the DataSet.Merge function:

  // Merge with the edited data
  casedata.Data.Merge(
    RefreshCasedatafromInputScreen(
    (CASEDATA)Session["UpdatedCaseData"]
    ).Data);

RefreshCasedataFromInputScreen was 120 lines of code; Brandon called an already existing function, saving another 120 lines.

All in all, he shrunk 363 lines of code (including the more than 240 lines of merge code) into three lines in about 45 seconds. Brandon shook his head as he explained to his wife that Mark had probably spent two or three days writing code -- which didn't even work properly -- when there's a built-in function included by Microsoft. The worst part: Brandon's team had shown Mark some examples of how to merge the data from their server into his UI.

Merge Disfunction
Brandon tried not to imagine what would have happened if Mark had tried to implement this type of craziness with all of the schemas and datasets they used in the project. The built-in DataSet.Merge function works with any dataset, while Mark's function worked only with the specific type of dataset for which he had coded. He could have spent weeks or months warping his brain to write merge code -- hundreds of lines for each different type of dataset. Had he only known about the merge function!

Mark finished by telling Brandon that he was so thankful Brandon could help him clean the code up because he was afraid the CTO would see it and tell him there was a better way. Brandon had to tactfully tell Mark that his code was the worst code -- and dumbest thing -- he'd seen in years. Mark was let go that week and Brandon's team had to build the portal in-house.

• Get Code Download