Prisoner of Process was originally published in Alex's DevDisasters column in the August 01, 2007 issue of Redmond Developer News

When Eric C. arrived at his new job, it was with a huge sense of relief. His old workplace had been a haven for cowboy coders and anarchic hackers, where the only semblance of consistency was in everyone's preference to modify code directly in production.

"Finally," Eric thought as he flipped through the Developer's Handbook. "Real processes!"

It's not as if Eric was a paper-pushing Process Nazi. He was just happy to see a bit of structure. But as he delved deeper into the handbook Eric grew worried. The processes seemed designed for a behemoth organization that had user advocates working with defect analysts to assess and manage issues in their software. But this company was a small financial services firm with no more than 30 employees. Eric paused, reassuring himself. "They can't be using this! It's probably just some old manual from the boss's previous job." He tossed the binder on his shelf and fired up Visual Studio.

The next few days went surprisingly well. Eric's coworker printed out a stack of issues for him to work on, and, one by one, Eric made his way through CAPP (the firm's core, in-house application) and resolved them. It was a great learning experience: He got to know the business, he figured out CAPP and he gained a strong understanding of its design. In less than a week, he was a bona fide CAPP expert.

Then Eric overheard one of the data processors chatting with Eric's manager. "But then, when I click here," Eric heard, "CAPP sets the asset value as blank!" Eric was used to overhearing the data processors' conversations. They all worked in a small room and sat no more than six feet from each other.

Eric had worked on the affected code, and began to chime in to the conversation when his boss interrupted.

"I'm sorry," Eric's boss said, "I know you're new here, but we all really need to follow procedure. Did you get a copy of the Developer's Handbook?"

Eric stuttered, trying to figure out his faux pas. "I, um, yes." Then it hit him. He recalled the specific rule he had violated.

It was in the Defect Pre-Assessment Stage: "To ensure developers aren't bogged down with unneeded defect assessment, only user advocates shall communicate with end users in this stage."

By the Book

Having skimmed the Developer's Guide, Eric had another look. The Defect Resolution process read as follows:

  1. Upon encountering a potential program defect, the user shall immediately cease performing any further actions in the application and shall e-mail his or her user advocate (i.e. Eric's boss).
  2. The user advocate shall immediately go to the user's workstation (which always required him to pass by Eric's) and then meet with the user (which always happened within arms-reach of Eric).
  3. After discussing the potential defect, the user advocate shall send an e-mail to a defect analyst describing the potential defect and requesting that an issue be created.
  4. The defect analyst shall then create an issue in the defect database (an Excel spreadsheet), assign a defect number (best guess at creating a unique, 12-digit random number) and fill out a defect report (a Word document on a network share).
  5. During their weekly defect-prioritization meeting, the development manager (also Eric's boss) and the defect analyst (the only two attendees) shall meet and assign defects to one of the three programmers.
  6. The defect analyst shall then update the defect database (both the spreadsheet and the document) with the assigned programmer and e-mail the programmer a copy of the issue report.
  7. After the programmer notifies the defect analyst of the resolution, the defect analyst shall notify the QA manager (also Eric's boss) during their weekly proposed-defect-resolution meeting (again, with only two attendees).
  8. If the resolution has any problems, the QA manager shall notify the development manager (perhaps in a meeting with himself?), who shall notify the defect analyst in the weekly defect-prioritization meeting, who shall then notify the original programmer, who shall then repeat the previous step.
  9. Once the resolution is deployed, the QA manager shall request that the defect analyst close the issue at the next weekly defect-prioritization meeting.

Over the ensuing months, Eric couldn't resolve a single defect. With an average feedback cycle of two weeks and all "outside protocol" communications forbidden, even the simplest change took months to resolve.

However, on Eric's last day at the firm, rumor had it that the QA manager was "seriously considering" notifying the closing of Issue #182749384701 -- the one Eric had been given four months earlier on his first day on the job.

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