Friday, July 25, 2014

Bugs that should not be fixed

Of course,  we want to fix everything. It's extremely difficult to justify sometimes why we should not be fixing some bugs. There is always an angle to more security, better usability, better look and feel, a new feature which could be a killer. The points I am mentioning are more valid near the release and hold less water in the beginning of release so take your judgement.
  • Usability is a never ending game. Understand your users. If they use application after going through training, then don't kill yourselves for usability. If you are making an application where user interaction is limited and the application expects many passers by, then usability is extremely important. A flight reservation site need to be high in usability than a mail application. Users are used to certain workflow. Even if it is suboptimal, don't change it drastically. If you want to change, then change it incrementally and span it across releases. There are many cases in history where the apps workflow is changed drastically in terms of look and feel to make it better. It became better, but the sales were lost and the company became history. If users are trained to find a button inside a dialogue, they will not appreciate immediately if the button is hanging over the menu. If you do not have the muscle of Microsoft to persist then better avoid it, especially in cases where there are similar competitors lurking in the horizon. At times,  it’s not about you making it better, but it’s about you have annoyed the end user by changing it.
  • The security mechanism has worked for a long time without any issues reported. There are no new identified threats. Let it go for some more time at the end of release and schedule it for the early next release. But be particularly careful of your trade off's. At least do not change the encryption level to a higher one, if customer is not holding the invoice for that. There will be enough migration headaches to take care of.
  • All the new feature requests (with a mandatory tag) come in the last week. One of the reason is that during those times, the higher management gets a feel/demo of application and they start realizing the gaps in the expectations. One way to deal with it is to, have more intermittent demos. If possible, have html wireframe mock ups, so people know what is coming out of the oven.
  • Colour and Font change request are also common. It’s better do them then trying to negotiate over them. It’s faster that way.

No comments:

Post a Comment