[PLUG] Bug-tracking software.

alan alan at clueserver.org
Tue May 15 17:46:44 UTC 2007


On Tue, 15 May 2007, Rogan Creswick wrote:

> On 5/15/07, alan <alan at clueserver.org> wrote:
>> On Tue, 15 May 2007, Aaron Burt wrote:
>> > On Mon, May 14, 2007 at 10:12:43PM -0700, Ronald Chmara wrote:
>> >> Something I've found helpful is to not introduce new *software* to a
>> >> team, but instead introduce new *process*.
>> >
>> > +1.  It's all about tha process.
>> 
>> Sometimes the process gets overdone.
>
> The last company I worked for had nothing but process for reporting
> bugs.  To give a bit of context, I was working in a cube less than 15'
> from the data entry people who used the application I was writing,
> when they found a bug, this is what happened:

[Dilbertesque process snipped]

Sounds like the person who came up with that process moved here.

But now they have the burden of testing the process and proving that it is 
fixed.  Not proving to the tester's satisfaction, but everyone else 
involved whether they understand the problem or not.

But that does not close the bug.  It has to pass audit after the next 
full run as well.  Except they space the full runs so close together that 
we can only get one or two fixes in between runs.  (The idea is that more 
will get done if we flog full test runs instead of longer fix and test 
cycles on individual components.)  And since the current process is set up 
in a way that we can only do one or the other kind of testing, it drags 
things out even further.  (We are working on getting a test server built. 
Still trying to scrape together the database space to do it.)

-- 
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
                                   - Alan Cox



More information about the PLUG mailing list