Kieran France Kieran France is a programmer for IDRSolutions. He enjoys tinkering with most things including gadgets, code and electronics. He spends his time working on the the JPedal library and our internal test suite..

Bug priority – Persistence is not always a virtue

1 min read

Persistence is not always a virtue, or at least not in all cases when it comes to bug priority. I have recently been working on improving various parts of the viewer examples user interface as over time some functions need improving to keep track with the rest of the application.

The first thing I needed to do was to identify what needs improving. This gave me a nice list that I started to prioritize. Many people, when dealing with bug priority, will take the biggest or most broken issues and put them right at the top of the list and up till now I was one of them. It’s an automatic response drilled in to me from childhood through school and university. You get the larger, harder most difficult tasks done first, small jobs can wait as these others are more important.

So I begin, working away. I make a change, test the change, rinse and repeat. Each time I am testing a change I ended up using a small piece of functionality that needs improvement because it might be slightly slow or awkward to use but that’s fine, it’s on my list, I need to do this first, it can wait.

Rinse & repeat, rinse & repeat,  rinse & repeat, rinse & repeat, rinse & repeat…

After the first hour I am getting annoyed by this small function that is further down the list.

Rinse & repeat, rinse & repeat,  rinse & repeat, rinse & repeat, rinse & repeat…

By the end of the day I have thought horrible things about the creator of this small piece of functionality (until I remembered it was me).

But this reaction got me thinking, if this is how wound up I got dealing with a small annoyance for along period of time, me who has access to the source and could easily fix it, what is it like for end users that can’t. I looked at my list again and began to reorder the issues, not just based on how big or broken an issue was, I also took into account how often the functionality would be used. Suddenly that issue I was working on originally at the top of my list was near the bottom as it is rarely required and the one that was bugging me all day was at the top along with several other smaller issues.

I have always understood the idea of weighting the importance of something based on frequency, it’s important when improving efficiency and speed of method. For example, improving the speed of a method called hundreds of times is often preferable to improving the speed of a method called only once. I just never really thought about applying a similar logic to the issues I am fixing.

So, persistence is not always a virtue, especially when it’s a bug.

Just for completeness I feel I should point out there are exceptions to the rule. An issue only encountered rarely that crashes the system compared to one that is used often and only slows down a process by a second in total. I think we can all agree one of these is slightly more critical that the other.

IDRsolutions develop a Java PDF Viewer and SDK, an Adobe forms to HTML5 forms converter, a PDF to HTML5 converter and a Java ImageIO replacement. On the blog our team post anything interesting they learn about.

Kieran France Kieran France is a programmer for IDRSolutions. He enjoys tinkering with most things including gadgets, code and electronics. He spends his time working on the the JPedal library and our internal test suite..

Leave a Reply

Your email address will not be published. Required fields are marked *