I often have to tell engineers who are very focussed on an issue to “take a step back” and think about why they are seeing/having the issue.
Recently an issue was noticed with one of the dialogs on our scheduling product. The issue only occurred on Firefox 3. The dialog displays a list of items and each item’s row height was growing to fill the available space in the dialog rather than the row height being set based on the height of the contents. It was only a cosmetic problem. One of the engineers tracked the cause back to a known issue in Firefox 3 with table rendering. I asked him if there were any known workarounds and he said no, we would just have to wait until the issue was resolved in Firefox.
Although it was only a cosmetic problem it bugged me! We were not doing anything special on this dialog. The dialog just displayed a list of items in an HTML table. If there was a widespread problem with table rendering in Firefox 3, then everyone would be talking about it. Take a step back and think about it – why were we being affected by this very specific issue?
On a Friday afternoon when I had a few minutes spare I got one of my team mates to show me the Firefox issue report, which detailed the very specific situation that led to the problem. The problem was caused when the table or cell height were specifically set. This was something we did not need to do so we should not have been having the problem. Our table was being dynamically generated with JavaScript so we had a look at the relevant code and found it was setting the height of the table body element, which was not needed in our case. We patched the code on a server and tested the dialog again and it displayed perfectly – Issue Resolved.
It took about 10 minutes to resolve this issue, which had been sitting around for a couple of months because no one had taken a step back to ask why we were having this issue. We knew what caused it but had decided it was a Firefox issue and would wait for it to be fixed.
The speed in which it was resolved in the end was due to
- Good system knowledge – we knew where the code was that was causing the issue
- A reproducible problem
- Two heads are better than one.
No comments:
Post a Comment