I've decided. My first official act as Chief Executive Officer will be to hire a Yes Man. Think about it: how could there possibly be a better way to receive feedback? I'll come up with some great, big idea and, just before I had a chance to realize how truly brilliant it is, I'll have some one already there, enumerating its pros and pros.

I see that Jimm's program manager has taken a similar approach. At a fairly late stage in the project, he hired Jimm to take on a quality management role so that he would, presumably, remind everyone how great the quality was. But Jimm wasn't content doing that; oh no, he had to go and find bugs, and lots of them.

You see, Jimm's manager, in addition to being a model leader, was also a cost-conscious one. He realized how completely unnecessary project managers, architects, designers, developers, and testers were for the phase of the project, so he and his small team prototyped the first few thousand lines of code and shipped the rest overseas to be completed. And then he brought in "all those other people," including Jimm.

Obviously, that caused things to get a little mixed up, so architects ended up doing the testing, developers did the project management, and Jimm's manager became the Issue Master. What that meant was that every bug that Jimm (or one of the other architects) found went straight to the manager for prioritization.

The issue prioritization process was fairly simple, too. A bug would be reported and the manager would defend it with his common reply, "I can see how you think that might cause a problem; it's not ideal, but it's not a show stopper, either."

Jimm received this reply when he reported a fairly serious design flaw: the code didn't have any transactional logic. A typical page request involved executing 20-25 different SQL queries and, if any of these failed (which, they often would), it would result in things getting in a strange "half-state." The only way to fix things after that was through several painful, manual crediting processes by customer service.

But Jimm wasn't satisfied with the standard reply. He knew it would be chaotic, especially when hundreds of simultaneous users were introduced to the system. Jimm argued, pushed, complained, and griped, hoping that his manager just might see the criticality of the issue. He even brought it up in a meeting which, as it turned out, didn't work so well.

"So what?" his manager barked, "our software has the **small** flaw of creating a few extra rows in the database. Big deal, who cares?!?"

The manager, furious, then instituted a change of policy: "I need you to stop reviewing the code and finding all of these 'issues'. We need a production deployment plan."

The message was clear.

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