Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 4 down vote favorite

Question: If you find a bug in a "classical" developement tool, you usually

  • prepare a minimal working example,
  • browse to the vendor's online bug tracker and
  • file a bug.

For example, you'd report a bug in .NET at Microsoft Connect, a bug in Java in Oracle's bug database, etc.

Despite being a very popular tool for the development of "line of business" applications (using an SQL Server backend and the royalty-free Runtime actually allows you to create scalable and deployable software), it seems almost impossible to just "report a bug" for MS Access.

Is there any option for (a) dropping a bug report and (b) getting feedback on its progress?

What I have tried:

  • The MSDN Access for Developers forum: It's a community driven forum, which means that it's a question of luck whether some Microsoft Moderator sees it and forwards it to the developers (Example 1, Example 2) or you end up just discussing the bug among other users, which is kind of a pointless and time-consuming exercise (Example).

  • The restricted partner forums: There's one for Office Access, but it explicitly does not deal with development issues.

  • Drop it into the general Office Feedback Form: Might or might not work, but you don't get any feedback and it really feels like dumping it into a black hole.

  • Open a support case: Tried that once:

    • You fill out a form and provide your credit card number. They promise not to charge you if it turns out to be a bug.
    • Submit your bug repro description.
    • Get a generic confirmation mail with lots of text and completely unrelated "useful" links.
    • Get a welcome mail from a helpful Microsoft Germany support engineer sending you his contact data and telling you how glad he is to help you.
    • Send him the repro description again.
    • Get a confirmation mail with a rewording of my problem description and an "action plan".
    • (One day later) Get a mail that the problem cannot be reproduced.
    • After a few more e-mails, call the guy on the phone and (virtually) hold his hand while reading the bug repro description to him, line by line. Now he can reproduce it.
    • (1-2 weeks later) The guy organized an "Access expert", and all three of us have a phone conference, where we basically restate everything that has already been said by e-mail or phone. They acknowledge that this is a bug, tell me that they will forward it to the developers, that it might or might not be fixed in the next service pack, that they are sorry for not finding a workaround. No, they don't get feedback from the developers after forwarding the report. I ask them to close the case.

    So, yes, this way kind of worked, but the cost (hours of e-mails and phone calls on my side) was immense.

Is there any better way? Some secret code to get a direct connection to the bug tracker?

share|improve this question
Sorry if the second part sounds a bit like a rant; I've tried to keep the first part (the question) as objective and answerable as possible. Feel free to improve. – Heinzi Feb 1 at 8:09
did you consider having a "visual recording" demonstrating how do you reproduce the bug? Plain video, or screen capture, or screen shots? From what you describe it looks like it was difficult to communicate bug description precisely – gnat Feb 1 at 8:30
@gnat: Good idea, I'll consider that next time. (Although the bug really wasn't difficult to reproduce, here's the description, if you are curious.) – Heinzi Feb 1 at 8:33
per comments at this link it looks like bug report has been successfully pushed through to dev, without too much effort on your side (except of course efforts for writing bug description, which is pretty good btw) - do I miss something? – gnat Feb 1 at 9:02
@gnat: It did. It's one of the positive examples of using the forum. (For this bug, I've tried the "support case" option first, then, while the case was open and I was waiting for a response, I thought I'd give the forum a try as well.) – Heinzi Feb 1 at 9:47

closed as off topic by Walter, MichaelT, Frank Shearar, GlenH7, Glenn Nelson Feb 5 at 22:53

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined in the FAQ. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about closed questions here.

1 Answer

up vote 2 down vote

Upon studying examples you provided, I would say that Access for Developers forum comes reasonably close to consider it the way to report bugs.

You mentioned that first two examples (thread IDs 620c946b-fb4e-4d82-963a-548e34409191 and 648dd3a2-28c1-4f0d-853c-ef932c58519f) went OK and I agree, these look like handled pretty fast and well. A substantial part of this is likely due to the fact that you wrote clear and easy to understand bug descriptions: all three examples (including "difficult" one) look really good, congratulation on that.

As for third example (620c946b-fb4e-4d82-963a-548e34409191), don't be confused with the fact that it turned out time-consuming. As far as I can tell, this is just the kind of bug that would have "difficult life-cycle" anyway. It just happens to some bugs, and I have seen this happen even to bugs submitted by professional testers in the professional bug tracking tool and evaluated by professional developers working in the same project, within the same company (a bit more on "difficult" bugs at the end of my answer, if you're interested).

There are of course couple of things that look suboptimal because of using forum as a way to report bugs. As you maybe noticed in what I wrote above, "bug IDs" extracted from thread URLs like http://social.msdn.microsoft.com/Forums/en-US/accessdev/thread/620c946b-fb4e-4d82-963a-548e34409191 don't look as convenient as traditional issue tracker IDs based on simple auto-incremented numeration. It is also interesting to note not quite intuitive suggestion in your "difficult" bug report, to create a new thread for posting with the new understanding: in a specialized issue tracker this of course would be a simple matter of editing bug description.

There are also some other inconveniences caused by the fact that bad tool (forum) is used for the job (bug tracking) but still, to me it looks like Access for Developers is capable of serving the primary purpose of reporting and clarifying bugs and passing these to developers.

As promised, a note about "difficult" bugs like your Date Picker example. These can indeed take much more effort and time to properly evaluate and justify acceptance or rejection. Thing is, in these, it is rather hard to point what is exactly wrong and why. Everyone seem to agree that observed behavior is "bad" and that expected one is "good" but everyone seems to having a difficulty explaining why exactly is that. This makes it hard to "accept" bug because there is no clear justification on why things should change; in professional software development, one can not change the code only because it "just feels wrong".

Another symptom of a "difficult" bug, also visible in your Date Picker example, is that those who evaluate it, tend to focus on describing details of how application works ("singling out what happens") and how it looks "logical" but, again, everyone seems to be having a difficulty explaining why it could be correct or at least why it could be unimportant (it would be "unimportant" eg if there was an easy workaround, in that case there would be an option to drop the bug report with conclusion like "low priority, not worth fixing"). This, naturally, makes it hard to "reject" bug because, well, there is no clear justification on why things should stay as is; in professional software development, one can not reject bug report only because "code is written that way".

Bugs of this kind are difficult in particular because these require substantial creativity to evaluate. Note that Date Picker example report still does not have clear resolution; this probably means that its "life" will remain difficult even now that it has been formally reported to developers - it will likely silently hang in there until someone discovers a way to explain things so that it will be possible to give it a justified "accept" or "reject". A bright side of this difficulty is, when resolution is finally discovered, it often leads to enhanced understanding of how application should work and how it should be used.

  • Side note. For Date Picker bug report example, "attacking" the problem from the consistency perspective looks promising, especially given your note that "in all the years I have used Access, OpenForm both put the form in front and set the focus on it". I would likely try to provide an "alternative" example, with a code similar to problematic one (ideally, with just a different format of TextBox) but one that would set the focus as expected. From this position, I would probably appeal to the fact that current behavior forces developer to memorize an undocumented and counterintuitive behavior in a particular use case, as opposed to generally observed behavior demonstrated in "alternative example".
share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.