If it takes two contract developers six months to drive a project to failure, then four developers should be able to fail in half the time! Josh assumed that was why he and Sam were carted out to the client site and tossed into the oubliette of the PowerPac project. They were armed with nothing but a rusty spoon and a requirements document so old it needed to be stored in an oxygen-free environment.

The original development pair was Sally "I can code but I'm more of a designer" Jorgensen (the CEO's daughter) and Billy "I taught myself HTML in a week and am now a programmer" Jorgensen (the CEO's brother). They ran the project exactly like you'd expect such a dynamic duo to run it- directly into the ground. By the time Josh and Sam joined, it was already well past deadline and over budget.

To make a good impression on the client, Billy and Sally didn't work out of the consulting firm's office, but instead moved to the client site. The pair had improvised a server room to work out of. It could be easily distingushed from a broom closet by the piece of duct tape with "SEVER ROOM" sharpied onto it. Inside, an overheating rackmount server balanced on a crate of toilet paper. On a sagging plastic card table sat the developer workstation running VS2005, which doubled as their source control box, since it ran Visual Source Safe.

Josh thought their physical environment was bad, and then he looked at their application. Billy, it seemed, had read one website on database design and walked away with the idea, "if normalizing data across tables is good, normalizing it across databases bust be even better!" Their wheezing Sql Server instance hosted a dozen databases, one for each entity and an extra DB to hold tblIncrementingIDs(strCurrentID VARCHAR(50)), so that unique IDs could be consistent across all of these databases.

The first and last thing Josh noticed about the web code was the fact that each page had a multi-megabyte ViewState. Coupled with terrible coding practices, Josh and Sam junked the VSS repo and then started laying out a plan to rescue the application. They moved the dev team back to the consulting firm's main office, where they had a true development environment, complete with modern dev tools and a well administered TFS2010 instance, along with labs for automated testing. They rounded up people from the client and pinned them down on requierments. They beat Billy and Sally about the head and shoulders with three-tiered architecture until the two of them got it, and proceeded to wrench the project back onto course.

Four months later, Josh and Sam had accomplished the impossible- twice. They had gotten Billy and Sally to turn out code that wouldn't flunk a 100-level college course. The slighly less impossible achievement was that they had turned the project around. It went from "this is never going to be finished" to "it's late, overbudget, but we're within striking distance of an actual deliverable product." They were on track to deliver in two more months.

This kind of success on a project draws accolades and back-pats and lunches paid for by the consulting company for a job well done. It also draws something far more sinister: project managers who want to steal that glory for themselves. Doug, from the client-site, was exactly that kind of project manager. In the closing months of the project, he swooped in with the promise to manage the hell out of this project and keep it on track.

Doug did everyone the favor of standardizing the process. The QA Officer (Doug) had to approve any code before it could be checked into source control. The Compliance Officer (Doug) needed a report of every file modified before any build could be run, down to the specific line numbers changed. He couldn't just extract this information from TFS because, "It's part of the developer's job!"

Only the Build Officer (Doug) could kick off a new build, and not using TFS (a developer tool). Doug would run builds from his own computer, and if he forgot to perform a Get Latest to ensure he had all of the changes, well, that was the developer's problem. They should have followed the communication plan.

Josh protested and escalated and did all of the things you're supposed to do when someone's tanking your project, but to no avail. He couldn't understand how Doug was getting away with this until he sat in on Doug's status meeting. Doug had compiled a PowerPoint full of pretty graphs and dashboards showing nothing but green boxes. He used words like synergy, Agile, "code coverage", "core principles" and "industry standard best practices". It was entirely fabricated nonesense, but management swallowed every drop.

When they didn't hit Josh's original target dates, the money officially ran out. The project was cancelled, and the client informed the consulting company that Josh and his team should never be assigned to one of their projects again. Doug got transferred to another "at risk" project for the client, so that he could "save" it.

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