Bug management systems

[Ben Rubinstein]

On 07/08/2010 14:56, wayne durden wrote:
> Given that almost all will indeed have excessive features, it seems like
> this might be a good use case for Rev and "eating one's own dogfood."
> Admittedly any prebuilt system has an enormous amount of man hours
> already in it, but it doesn't seem like a bug report system needs to
> start with more than 15 or so fields and Rev is ideal for incrementally
> adding a feature such as a new report type as the need arises...
>
> It has bugged me a little in that if Rev is so ideal for some of these
> things, why isn't the maillist, bug syetem etc. done in Rev?  It sent
> mixed messages to me at least to get a Python or PHP based list signup,
> etc.  Now I fully understand the rationale, each of these things is
> proven and has a ton of manhours already invested in discovering the
> "gotchas" that crop up as time passes, but still, it generates a mixed
> message when juxtaposed against the main selling claims related to Rev.

I'd really hate RunRev to waste resources doing this.  If they were to write 
their own bug tracking system, mailing list etc, then I'd certainly expect 
them to consider using their own dog food (but possibly decide to use 
something else); but unless there's really nothing available that's "good 
enough", they should focus on their core job of improving and selling the 
product, not distract themselves by building from scratch what can be 
economically purchased.

As a programmer, with a load of programmer colleagues, it's taken me years to 
learn to resist the urge to roll our own.  Gradually we've replaced the 
internally developed intranet calendar, the internally developed bug tracker, 
the internally developed CRM system and many other pieces, with products or 
OSS.  Each move was a step in the right direction in focusing on what we could 
do for our clients.  Frankly products are probably a better move than OSS in 
this respect; for the equivalent of perhaps half a day's rates, we get the 
product of months of work by someone else's developers, with someone else to 
do support and fix bugs; the inability to change the odd aspects that we don't 
like are probably outweighed by the inability to waste staff time fixing those 
aspects.

I cry when I recall that in the infancy of our company we kept our accounts 
using a system written by our MD in Prolog!

Ben