Development Manager. Yeah, it was a Pointy-Haired-Boss title, but Jamie was ready for that. He had put in his years as a developer and knew it was the right time to move on to management. Besides, the team he'd be managing was fairly small, and he could always jump in to help out with some coding if needed. The offer was just right and, like that, Jamie became a manager.

The company was a business directory publisher and, for the past quarter century, had outsourced the majority of its software development to an IT consulting firm. And by "consulting firm," I mean a one-man company employing a single consultant. And by "consultant" I mean, a guy whose twenty-five years of experience came from his one and only client, the directory publisher. This consultant was who Jamie and his development team would be competing with to provide client departments (Accounting, Editorial, etc) with applications.

Over the years, the consultant had convinced people in the business that his way was the right way of doing things. That, in and of itself, is a rather impressive feat. As an example, his invoicing application could never have more than three items on one invoice; this lead to some interesting situations for the accounting department, but they learned to deal with it.

One of Jamie's first acts as manager was oversee the deployment and testing of the consultant's new CMS application for the editorial department. That's right: deploy and then test. It was apparently the right way to do things.

Deployment was a cinch: the consultant walked around to all of the users with a USB memory stick and copied the application directory to everyone's computer. No "network push" installation, no installer – just a simple copy of the consultant's "\bin" folder of compiled code.

The testing strategy was a bit more interesting. The consultant sat at a desk near the front of the room where he was physically able to see all of the editorial staff. With a booming voice, the consultant told everyone to double click on the desktop shortcut and raise their hand if there was a problem. Everyone's hand shot up: it turned out that no one could be authenticated to login to the application.

The consultant took a few minutes to look into the problem and immediately blamed Jamie: "umm, when did everyone change their computer's name?"

Having no idea what he was talking about, Jamie checked with the network admin staff. They explained that, three years ago, they switched from having workstations named after its user (CHRIS-ADAMS) to naming workstations with a standardized identifier (WKST-ED-09), and that the consultant's CMS system was using the workstation's identifier to passing into the database for user authentication.

Before Jamie even had a chance to get back to him, the consultant was already working to fix the problem. He got a list of all the Workstation ID's and added an extra column to the User table so he could determine which user was connecting. After another round of deployment, the consultant gave the "double click" order and, once again, everyone's hand shot up: no one could see any data.

The problem this time was that the "local database" was not working. The application worked by replicating the live database to a database on the user's workstation, and then merging the live and local database when the user closed out the application. The consultant's code required that users of his CMS application not only be administrators of their local machine, but administrators on the database server.

It was a tough sell, but the network administrators finally gave in to the client department's pressure and made everyone in the editorial department and administrator. Another round of testing began and this time, after telling everyone to "double click," no hands were raised. The application was working.

A few hours and several "raised hands" later, the consultant realized that there was a bit of a problem: two users might want to edit the same record. This would cause a conflict when the local and live databases were merged. Before Jamie could say "optimistic concurrency replication," the consultant was already hard at work on another fix: records would be "partitioned" across users, so that one editor would only see the "A through C" records, another would only see "D through F," and so on.

Though the editorial staff wasn't too thrilled about the change, they understood that it was the right way to do things and agreed to change their process.

By that point, Jamie realized that his days were numbered, and there was simply no way he could compete with the consultant. It also explained why the company had such a hard time retaining development managers. Jamie tendered his resignation, sought a job elsewhere, and just like that, Jamie became a developer again.

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