by Adam Juda on Tuesday, April 19, 2016
I was working with a software company some time ago. The firm was in crisis. Builds were breaking. Requirements were going unmet. Managers were desperately trying to figure out who might be willing to spend actual money to buy the firm's products.
Nevertheless, the company was somehow flush with cash and on a hiring spree. Before you knew it, the headcount had doubled and the main office was flush with new ideas. Many of the new hires did their best not to rock the boat. Others wanted to make names for themselves by championing new initiatives.
As it happened, I had a desk near one of the latter. Within days, the demands for changes began. Within the first week, the new engineer had held many meetings and pushed hard to not only re-write large sections of the software, but also change the technologies being used.
The vast majority of the engineers were beside themselves. This push for change made no sense - not only were resources stretched thin, but there was little possibility for gain. Nevertheless, the new hire was persistent and spoke passionately to the management team. Soon the decision was made. Large sections of the system would be redesigned and re-coded using the new technologies.
Weeks later, the changes were complete and ready for testing. The revised system functioned poorly. The engineers who had originally poopooed the move were furious with rage. A ridiculous number of man-hours had been wasted at a time when the value of every second was at a premium.
The call to remove the new hire's changes became quite vocal. One of the more educated staff members pointed out that reverting the alterations was a no-brainer. The older version was clearly superior by any metric that could be imagined. He also pointed out that the resources invested in the new system were no more than a sunk cost, so they could be completely ignored.
Surely our new employee would agree, right? His interests would be aligned with those of the company? No! If anything, his resolve only hardened. He fought tooth and nail against the removal of the new code, no matter how clear and logical his opponents' reasoning. His coworkers didn't understand. The cost of switching back to the previous version would be minimal - a simple pull from the repository would bring the system back to its original state. It would deliver an exceedingly high benefit at minimal cost. Why would the new engineer be against such an obviously good decision?
The problem was that few understood that the costs of revision would far exceed that of "a simple pull." There was an associated cost that was far more insidious. The engineer who pushed for the changes would be forced to admit that he was wrong - the cost would be his credibility. Whether or not going back and admitting he had been wrong would be good for the firm, it would certainly be terrible for his profile at the company. It was a clear case of the principal-agent problem.
So he continued to argue. The more he argued, the greater the cost of backing down. In fact, it became his sole mission at the company. He'd never voluntarily back down. To this day, the inferior code remains in place and few are willing to argue for its removal, lest they become subject of the engineer's wrath.
Many people think that prices are only paid in dollars, but costs can be measured in almost any unit. Even pride.