Change Management

A single Excel spreadsheet on a network share drive that hundreds of developers update daily leads to disaster.

"Wait a sec," whispered Chris's coworker David. "He can't possibly think this will solve the build problem?!"

Chris nodded slightly, uncomfortable to be part of a private conversation in the middle of a huge team meeting. "I mean, seriously," David continued, "this will only make the problem much ..."

"Oh, I'm sorry," the chief development manager barked. "Were you guys trying to have a meeting in here? Because if I'm interrupting I can stop. I'm sure all 53 of your colleagues sitting here have nothing better to do than to wait for your little meeting to end."

David and Chris stared blankly, their mouths agape.

"Oh. You're done? Great! Let's continue, then. That OK with you?"

That was exactly what Chris was trying to avoid. He had witnessed similar outbursts and he wasn't too thrilled to be at the center of one this time around.

Deep down inside, the chief development manager could have been a nice guy, who just liked to dish out tough love. But he wasn't. He was a cantankerous, spiteful little man who wielded a lot of power and used that power to make everyone around him miserable. His latest idea -- the new build-and-deploy process -- was another step in that direction.

3:00 Check-In
David was right-the new build-and-deploy process was ridiculous, and with hundreds of developers spread across four offices around the world it would never work. But the chief had staked his reputation on it. It didn't matter what anyone said -- they were using his process.

The new plan was to have a fixed build schedule with strict deadlines. If a developer didn't get his change in by 3:00 p.m. Tuesday, then that change wasn't happening. No excuses, no exceptions. To manage all of these changes, there would be a single Excel spreadsheet on a network share drive that each developer would be responsible for updating. They'd have to add a row for every file changed and include its path, the issue number and the reason behind the change.

To almost no one's surprise, the first build using this new process was a complete disaster. Most developers spent all of Tuesday fighting over the change spreadsheet, desperately clicking it and cursing the "this file is currently in use by ..." dialogs. With all the haphazard updates, the build wouldn't even compile.

The second build, third build and fourth build all suffered the same problems. More than 200 developers trying to a share a single spreadsheet around a hectic build schedule just didn't work. The management was getting a bit fed up with the lack of working builds on their test environments and went straight to the chief for an explanation.

Power Play
The chief passed the blame on to the dev managers and the developers. He voiced concerns that they might even be trying to sabotage his system.

"This is complete crap!" David complained to Chris, as they sat in another developer's cube. "Does management actually believe that? I've put in a helluva lot of hours this year, and this is just going to kill our bonuses! I'm going to say something. This just isn't right!"

Chris agreed, but cautioned his coworker about raising a stink. Everyone knew that the chief was not one to be messed with. But David ignored Chris's advice and started gathering a small group of developers. Together, they'd set up a meeting about the build process, invite executive management and directly confront the chief development manager. They would not put up with his underhanded tactics.

The wily chief didn't get to where he was without people skills. He covertly told management that their attendance at a meeting about the build process was a waste of their time, and that he'd distill the results to them later.

David and his fellow developers waltzed into the conference room expecting a big confrontation, only to find the chief dev manager calmly sitting down, feigning eagerness to listen to their complaints. Then he forcefully declared that there was nothing wrong with his system and he didn't appreciate lowly developers telling him how to do his job.

Tell Us Your Tale
Each issue Alex Papadimoulis, publisher of the popular Web site The Daily WTF, recounts first-person tales of software development gone terribly wrong. Have you experienced the darker side of development? We want to publish your story. Send us your 300- to 600-word tale -- if we print it, you'll win $100 and an RDN T-shirt! E-mail your story to Senior Editor Kathleen Richards at and use "DevDisasters" as the subject line.
A week later, the chief approached David and fired him on the spot. Each of the developers who had taken part in the build-process meeting with "management" met with the same fate.

The next day, the chief development manager sent an e-mail to all developers letting them know that, effective immediately, a third-party build-management system would be used to manage changes. A slightly different e-mail went out to the executives, informing them that the problems behind the new build process -- meaning the developers he'd just fired -- were now solved.

It wasn't all for naught. Chris received an e-mail a few weeks later. It was from David. "Chris, my new job is fantastic. And best of all, there's no chief development manager."

About the Author

Alex Papadimoulis is a managing partner at Inedo LLC and publisher of the Web site "Worse Than Failure" ( He writes the DevDisasters page in every issue of Redmond Developer News.

comments powered by Disqus

Reader Comments:

Add Your Comment:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above