I was chuckling over MonkeyUser this morning...
And then I got to thinking: can this ever be done right? Can you really promote a bug to a feature, but deliberately and usefully?
We often speak about bugs as if they're literal gremlin-like entities residing in our code, but they're usually just a flaw in our implementation logic. We meant to do X, we did Y instead.
What if some of those mistakes are really happy accidents?
The sort of bug I imagine as a candidate would have to be a Bohr bug with a predictable, yet presently unexpected (and probably undesired) outcome.
For example, imagine a list view in a GUI. When you click on the
Add Item button, you get another item...but the contents of the previously selected row are unexpectedly included. The user now has to remember to change all of those. Ugh! That's a bug.
The usual approach would be to rewrite the code for the
Add Item button. But what if, instead, you rename the button and its code to
Duplicate Item instead. You promote the bug to a feature. Then, you go back and define a brand new
Add Item button that behaves as originally expected.
That's a painfully simple and obvious example, of course, but the idea is there. How many sorts of these opportunities do we miss?
At the same time, I see some potential issues if this is done wrong:
The implementation of the bug-turned-feature would still need to be fully understood and tested. You don't want the new "feature" to have side-effects or develop other unexpected behaviors.
One shouldn't use this approach to cover up actual mistakes. Take responsibility for bad code, even if you turn it around and make the most of it.
What do you think? Is this really a missed opportunity for improving code? What problems might exist? How should this be done for it to be successful, or should it be done at all?