This bit of advice is now considered “old hat” but I believe “Don’t flip the bozo bit” came out of a book by Jim McCarthy in his book ‘Dynamics of Software Development’.  (corrected)

The intent of the advice, of course, is to say that a development manager shouldn’t decide that a particular team member is “not with the program” and write off their advice, for any reason.  That is because people can be right, or they can be wrong, but they are rarely consistently one or the other.  A person can be “bang-on right” about one thing, and “dead wrong” about another, and a dev manager has to keep an open mind.

We sometimes don’t follow that advice when dealing with our own customers.  That is a shame.

My prior post engendered a response from a member of the “non-IT” community that complained that, when their department approached IT for a workflow solution, they got some bits about roles and authentication, but nothing for workflow.  They are solving the problem without the help of IT.

While I cannot speak to that situation, because I’m not familiar with all the details, I can certainly draw a parallel to a situation that I have seen while working at a different firm.

In this firm, most of the data was locked away in mainframe computers.  There was no SQL interface to the data, only CICS screens, which could be easily consumed by PCs using screen scraping techniques… as long as the fields didn’t move around (a hazard with screen scraping systems).  So, the business and IT got together and decided to develop a special set of CICS screens that could be used by programs.

These screens would just have data, in a simple stream, so that programs doing the “scraping” wouldn’t have to do a lot of work to find the field.  They don’t “move around.”  The scraping is simple and the interface would work.  The business teams were delighted, because they could write their own little applications to automate tasks, while the IT department could stop being a bottleneck for small business-level requests that never seem to rise up the stack.

Months went by.  The dev team decided to release two CICS screens that contained a wide array of data, from dozens of other screens.  Security for the fields became a problem.  So did all the back-end cost needed to join all that data, because in the past, the screen scrapers would only ask for the data they needed… now they got everything, and the cost of using the interface was rising.  Documentation was sparse and not openly shared.  Add to that, as the business changed the main screens, someone in IT thought it would be a good idea to change the ‘scraper screens’ to stay in sync.  There was no way to request a particular version of the screen or even to find out what version was being displayed.

As a result, the business value was lost in implementation.  IT blew it.  Here’s the funny part: they blamed the business customers.  They said that the business customers had asked for too much data, that it was too complicated to maintain, and that they complained when the screens were updated (they never complained when the ‘human usable’ screens were updated).

After a year, the project was scrapped.

So what happened?  Well, the point of the project was lost in the implementation. 

When I interviewed the developers of those CICS screens, it emerged that the business analyst (requirements gatherer) had “flipped the bit” on his customers.  The dev team had five people, in the business, that they normally worked with to get requirements for this screen.  One of the most annoying and persistent folks had insisted on things like version numbers and a stable interface, but he also insisted on all the data coming back on a single screen.  They called him “Mr. Noisy.”

At first, they listened to Mr. Noisy, but as it became clear that returning all the data on a single screen was becoming expensive on processor time, they ‘flipped the bit’ and stopped listening to him altogether.  All the other good ideas, about a stable interface, version numbers, standard field identifiers, open documentation, etc, that he was pushing for was ‘flipped’ as well.

The rest of the business users were easier to work with.  Eventually, Mr. Noisy went away and the project delivered junk, and the project was killed, and no one cared.  Mr. Noisy was the person who wanted it in the first place, even though he had convinced others that they could benefit.  No one saw any benefits.

Classic failure.  Why?  Because the one person who had 20 good ideas had one lousy one, and the dev team didn’t have the guts to push back against the bad idea but honor the good ones.

Moral of the story: Ignoring “Mr. Noisy” may be easier, but you could lose good ideas and possibly the business value of the project.  Keep your noisy customers close.  Listen to them.  Tell them why their good ideas are good and their bad ideas are bad.  Only then can you actually deliver value.