Assignment 1 Bug Reports

Your assignment submission is not complete

Let me explain...

It's a strange thing about university assessment that students can be almost encouraged to submit something that they know doesn't work under some circumstances, and hope that the marker doesn't notice!

Especially strange, because we're in an industry where it is often acceptable (not really "ok", but acceptable) to provide code that doesn't work properly. (Heard of bugs in commercial software?)

There are two ways that this can be handled

  1. The lawyer's approach, which goes something like "We don't warrant that this software does anything in particular. We certainly don't warrant that it does what you paid us to make it do. If you want to use it, tick the accept box, and if you find it useful be happy...." Mmmmm...
  2. The professional's approach: "The following document outlines known concerns with the software (hereafter referred to as 'bugs'). The software has been studied and tested thoroughly, and all bugs that have been found are reported here in sufficient detail to allow further investigative work..."
Of course, I think that you should behave as a professional.

Final Journal Submission

So, by Friday September 13 (please email Mike if this causes you any great inconvenience) you should provide a further Assignment 1 Journal Submission which reports on any bugs you can find in your submitted assignment 1 code.

If in addition you have recommendations as to how those bugs can be resolved, please do include that information too and it will be taken into account in the marking.

Of course, it would also be wise to further test your code to try to locate any remaining bugs so you can report on them in your bug report.

You must submit a bug report even if you believe that there are no bugs to report. If that's really the case, do tell me (and it would be wise to say something about how you can be confident, what kinds of tests you carried out, etc).

What is a bug?

Any known differences between your program's performance and the assignment specs is a 'bug' and should be reported on.

It might be that you have not provided some functionality ("my program does almost everything, but it doesn't print the modes because I didn't have time to write that bit....". It might be that your program prints numbers in hex instead of decimal. It might be that your program works well but sometimes rounds incorrectly, or fails to terminate when there is negative data included or ...

You get the idea. It is very important to report on anything which doesn't meet the specs as laid out in the assignment. In addition, as described in the assignment, your program's output will be compared with the output from my program (mikesa1), so any differences you identify should be reported.

Always, we are only concerned with valid input, so it doesn't matter what your program would do if it was given invalid input -- there is no definition of the required behaviour for invalid input, so whatever your program does is not a bug. (Of course, if this was software we were going to release we would require the inclusion of error checking code and many other things, but they are not part of this assignment.)

How will your program be marked?

As described earlier, the program will be tested by an automatic script which will most likely detect bugs that are present. In addition, your journal submissions, and most importantly your bug report will be taken into account in determining a mark for your assignment.

In keeping with real-world practice, the presence of a bug, while undersirable, may not significantly reduce your mark if it is well-described in your bug report. Conversely, the presence of a bug that you don't seem to know about, based on the fact that you haven't reported it in your bug report, is a serious concern and will likely harm your mark significantly.

It might seem somewhat perverse, but if you have tested your program so well that you have identified and reported a bug that my test script does not locate you will be rewarded for the thoroughness of your testing and the quality of your reporting. Yes, you can get a better mark by reporting a bug that the marker didn't find.

So, what should I write?

Your bug report should be clear and succinct. It must be easy to tell exactly what you are reporting as a bug (perhaps you should number each bug for example). You should keep your report brief, but some words about exactly under what circumstances the bug occurs, why you think it might be there, what you might do about it if you had more time, etc, will certainly be useful.

Please think of this as a chance to demonstrate your intelligence as a developer. Show me how well you understand your own code's limitations, but do do it succinctly.

Final words

I hope that you have learned a lot about assembler, and have come up with a good implementation of the stat program that you understand well. Most importantly, I hope you undersand and can describe well its limitations.
Mike, 6 September 2013.