This post is part of the Pride & Paradev series.
Should you raise trivial bugs?
You should raise trivial bugs
Some of the world’s best companies have become that way through attention to detail. There are lots of famous stories about Steve Jobs when he was in charge of Apple about his pedantic nature. For example, how he would debate for half an hour about the shade of grey for the bathroom signs in Apple Stores. Another example is how he rang Google’s Vic Gundotra at home early on Sunday morning to let him know the shade of yellow of Google’s logo was wrong on the iPhone but Steve had put an Apple engineer immediately on it.
Raising trivial bugs is paying close attention of detail. Whilst customers might not notice something so little that is wrong; from little things big things grow.
You should raise trivial bugs even if you choose not to fix them, that way you can keep a list of known bugs you will release into production should you choose to fix them one day.
You shouldn’t raise trivial bugs
The problem with raising trivial bugs is that it slows your velocity and takes focus away from other things: namely building new functionality to release to customers.
If you focused your effort on fixing 100% of every issue ever identified with your application you will never actually ship the thing but continually try to perfect it. Fixing a trivial bug may then further highlight over trivial bugs and so the cycle begins.
By the time you release your application, a trivial bug may not even matter that much as it may be on a feature that won’t even be used: but you can only find out this by releasing your product into production: trivial bugs and all.