The Power of Babble
Recently, while engaged in an office conversation about the usual stuff, you know, latest projects, roadblocks, what have you, I heard again that painful paragraph that infuriates me. "My boss met this expert who told him that the development we were doing was all wrong and we need to redo it in Java. So today, my boss came in and told me to stop what I was doing and change all of the code to Java."
While I don't argue the merits or disadvantages of deploying the solution in question, I take umbrage with a stranger making an assessment of a situation and within ten minutes dismissing what could be months of effort simply by stating, "It's wrong." How would the expert know? This begs the old adage of walking a mile in another man's shoes before telling him what's wrong with him. I resent a know-it-all who really knows nothing about why decisions were made, telling me that those decision are wrong.
In the case in question, the developer has been using
Visual RPG to develop a special-purpose application. I won't debate the wisdom of the choice of compiler since I don't know the reasons it was chosen. Off the cuff, I probably wouldn't have gone that route, but the fact remains that this is the tool that was chosen to complete the project and address the business need. The project is nearly complete. Finishing touches are being discussed and then the boss meets some techno-pontificator who says it's the wrong solution.
Who's worse; the techno-geek who speaks without knowing the circumstances or the boss who listens to the babble? Frankly, they're both dead wrong, but the boss is worse. I wonder if the boss would listen to his accountant telling him that his plumber is using the wrong tool.
A good manager will listen to input from all relevant sources and work to reach a reasonable and logical conclusion. The manager in question in this case only listened to the techno-geek and did not take the time to discuss the comments with his people prior to making his decision. A good manager is aware that they are in the business of running whatever business they're in, not in the technology business. Perhaps when he realizes this he'll add more value to his organization and cause less aggravation for his people.
Here we are again at a point where someone in a position of authority needs to be reminded that the business should drive the applications, which, in turn, should drive the technology. Any deviation from that course usually results in a failed project. The blame for the failure is usually summarily pushed onto someone who doesn't deserve it and the company goes on making bad business decisions. There are no exceptions to the rule of business-to-applications-to-technology.
Although a project that doesn't follow this mantra can succeed, it will do so at greater cost and resource usage than it should. In addition, if it is successful, it often does not meet the real business need but rather drives the need for more required technology that the business doesn't need. It's a vicious circle and if you take your company here, you've done it a disservice.
So please, the next time someone throws technology, any technology, at you just for technology's sake, take a moment, reflect on how ludicrous the request is, formulate a response and then feel free to beat the requestor over the head with a copy of this column.