1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
How users can help developers fix bugs
A software bug (crash/unwanted behavior) is always a bummer, and developers
usually want their software to be useful by their users.
To help software developers fix your bug, it helps to understand how
they think about bug fixing:
Question 1. Do I understand the behavior the user doesn't like?
A computer program is a precise machine that when you give it <X> inputs,
it performs <Y> actions, and developers think about the software in that
same way. To help the developer understand what is wrong, provide this
information:
a. I performed <this specific set of actions>
b. The software did <something I did not like>
c. However, I expected it to do <something else>
A bug can't be fixed without these three critical pieces of information.
If you don't provide them at the start, then the programmer has to track
you down and discuss the matter with you. For many developers this makes
the problem "hard" and they may lose interest. You want your bug report
to scream out "this is easy!" to the developer.
Rule #1 -- If the programmer does not believe that you clearly understand
whether something is a bug or not, he will assume it isn't, and
go work on something else.
Question 2. Can I reproduce this problem myself?
Bugs fall into two categories 1) Reproducable and 2) Non-Reproducable.
The first thing the programmer will try to do is perform the steps in 1(a)
above. This is the first moment of truth. If the programmer is unable to
reproduce the problem using the steps you provided, he will make a snap
decision on whether the problem is important enough to spend a lot of time on.
If he decides at this moment the problem you describe isn't as important as
other things he has to do, then game over -- he won't fix your bug.
Rule #2 -- A bug that cannot be reproduced at will through a clearly
designed set of steps cannot be properly fixed. If you
make the programmer do the hard work of figuring out what
set of steps reproduce your bug, he may go work on something
more fun.
Rule #2b -- Good developers will not "fix" a bug that cannot be
reproduced, because that invariably breaks something else,
and they don't want to make your life even worse.
Poor developers will fix a bug without understanding why
it is broken, just to make you go away.
Question 3. Can the software be changed in the way the user wants?
Once the developer understands what you didn't like, and he can reproduce
it himself in his environment, he needs to know what the "fixed" behavior
should look like.
But programmers are human beings too -- and they have their limitations.
Sometimes it's easy for you and the programmer to agree on what the program
*should* do in this situation, but the programmer may not actually have the
skill to make the program do that.
The programmer combines what you wish would happen, with what he knows he
can make happen, and compromises with you on how to fix the bug
Rule #3 -- If the behavior you want is too hard, or will take too much
time, the developer may log the bug as "to do later" and go
work on something else.
======================================================================
Example:
=======================================================================
You have an input file with three lines in it:
Canary
apple
Bob
You run this file through the sort program.
$ sort < myfile
It outputs this:
Bob
Canary
apple
Wait -- what? This isn't right you think -- Apple clearly comes before
Bob and Canary. You might think "this program is broken and the developer
should be fired".
But a well written bug notice will get attention!
Dear developer:
I have a file containing three lines
Canary
apple
Bob
I ran this through "sort < myfile"
It gave me this output
Bob
Canary
apple
But I was expecting to see
apple
Bob
Canary
Can you tell me if this is a software issue?
Thanks!
User
The developer can look at this and say to himself, "hrm. this doesn't seem
right, does it", and he will create your text file and run it through sort
on his machine, and he will get the same results you do.
He would investigate the sort program and determine that by default, the
sort program is case sensitive by default -- and that all capital letters
come before lower case letters.
But there is a flag you can use to change this behavior, -f.
So if you do
$ sort -f < myfile
It will output
apple
Bob
Canary
So the developer will send you an email back:
Dear user,
By default, the sort command is case sensitive, and lower case
letters come after uppser case letters, so 'Z' sorts before 'a'.
That is why 'apple' comes after 'Canary'.
There is a flag, -f, that makes sort case insensitive.
Can you please use 'sort -f < myfile' and confirm this works for you?
Thanks,
Developer
|
