Bugslayer

His name was William and he worked on a troubled team. Their product was very successful and had been around for a long time.

The longer the product persisted, the worse its quality problems seemed to become.

Sever bugs in production were a regular occurrence and one developer always seemed ready to leap into the fray. They called him “Bill the Bugslayer”.

The worse things got, the more he seemed to thrive. He reveled in his reputation and in the nickname that went with it.

If there was a bug, he didn’t wait for prioritization. He didn’t wait for permission. He didn’t wait for repro steps. He just attacked.

His vigor for bugslaying was understood and respected by all. The bigger the effect of the bug, the more business lauded his victory. The more difficult the fix, the more impressed his peers were by his success.

Of course, he never missed a chance to let people know about his conquests.

The team had a “no time to get it done right” attitude. Instead, their culture was “close it right now”. The hyper-focus on immediate results and the glory showered upon William blinded everyone to the fact that their bugfixes tended to create more problems than they solved.

The product went into maintenance mode and no new features were to be added. Yet the workload continued to increase. Quality problems caused growth to stall, more or less calcifying the current user base. Still, the pressure climbed.

Eventually, someone noticed that the problem wasn’t how many bugs they were fixing. It’s how many bugs they were writing. They agreed to do things a new way, where they finished their work completely before they moved on and took measures to ensure that fixing one issue didn’t create multiple new ones.

Bill was unconvinced. Some think it’s because he couldn’t see his place in the new world. Some think it’s because he genuinely didn’t understand. Whatever the case, he refused to take a disciplined approach and continued to thrash head-on against every problem until he was convinced he could claim it was fixed.

The team could not fix problems as fast as Bill the Bugslayer could create them and they decided to build a new product. The new product was not a solution to all their old problems. It was a place where they could work free of William’s influence. Yet it was a smashing success.

Still. The same way Bill the Bugslayer wouldn’t give up his old ways, there were customers who wouldn’t migrate to the new product. They continued to pay higher support fees for a legacy system that was dwindling in its user base.

Eventually, it was just a handful of stalwart customers, Bill the Bugslayer, and all the bugs he could write.