We're having that discussion at work

Post #211,511 by drewk 6/17/05 9:35:28 AM 6/17/05 9:39:36 AM Reply	We're having that discussion at work Or more accurately we've already had it, but a few people haven't fully come around to the obvious rightness of my conclusion yet. Bottom line is I don't draw a distinction between bugs and feature requests. As far as the user is concerned, the application doesn't do what he wants it to do. We need to know that. All that's left is to decide if we're ever going to make it do what the user wants, and when that's going to happen. Once you've bought into this idea, having different systems for tracking bugs and feature requests seems really counter-productive. As for estimated completion dates, I take the view that you estimate how long it will take to do, then you schedule a completion date. If the developer misses it, he learns to estimate better. [edit] Caveat: This assumes you have some control over who is allowed to submit bugs to the system. If you're talking about open submission from an audience of potentially hundreds of users, then yes, you need something separate like Bugzilla. And someone whose job it is to pore through that list and filter out the duplicates. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com] Edited by drewk June 17, 2005, 09:39:36 AM EDT Expand All History
Post #211,526 by Steve Lowe 6/17/05 10:43:43 AM Reply	ICLRPD (new thread) Created as new thread #211525 titled [link\|/forums/render/content/show?contentid=211525\|ICLRPD] -- Steve
Post #211,722 by systems 6/20/05 2:17:04 AM 6/20/05 2:21:27 AM Reply	Generalization, Abstraction, Taxonomy, Perspective, Opinions Well, bugs and features have a lot a common. Like dogs and men. Bugs are trackable, Feautures are trackable Dogs have legs , men have legs Bugs are introduced into software by programmers, Feautures are introduced into software by programmers Dogs have teeth, men have teeth Anyway, you got my point ... A bug is a behavior that you want to remove, a feature is behavior you want added but from many perspective what you can do with them is the same We can track bugs and features the same way, and yes a smart programmer would use hard learned object oriented concepts like absraction and polymorphism to write a piece of software that would track -trackable work related to software products- and offer extensions that support specialized -trackable work related to software products But, I also think it is not always practical to generalize every problem you try to solve, or better said not too far generalize, else you can always end up with a general purpose programming language! or Perl 6. A good bug tracking system is one that is crafter for the special requirement of bugs even if they are minorly different from features. A good programming environment or framework, will allow you to share code between similar systems, and extend/specialize where neccessary Edited by systems June 20, 2005, 02:21:27 AM EDT Expand All History
Post #211,744 by ChrisR 6/20/05 12:16:32 PM Reply	Feature requests are classified as requests to add bugs Since adding new features will generally introduce more bugs into the software. :-) Bugs are stuff that should be addressed as the software does not meet the specification. Features are attempts to change the specification. Bugs should be immediately addressed. Features have to be pruned because, as a general rule, the end users want the software to do everything possible (and many things that are not computably possible).
Post #211,753 by drewk 6/20/05 12:35:08 PM Reply	Problem is, the users know that Which is why they will work as hard as possible to classify everything they bring up as a bug. "It doesn't work right." But it does exactly what you asked for. "But it doesn't work right ... and it's affecting our productivity." Right, so you should have asked for the right thing to start with. "But it doesn't work right ... [cc: CEO, CFO] ... and it's having an immediate negative impact on profitability." Oh, you mean it doesn't work right? I'll get right on that. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #211,755 by ChrisR 6/20/05 12:45:09 PM Reply	Customers will call on every person in the company... ...until they get the answer they want to hear.
Post #211,773 by folkert 6/20/05 2:18:25 PM Reply	Like I do for Comcast? -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey* [image\|http://www.danasoft.com/vipersig.jpg\|\|\|\|]
Post #211,831 by static 6/20/05 9:30:36 PM Reply	That's when you hold up the spec doc. And say "That's not what you asked for. What you're asking for is additional development and subject to normal scheduling concerns." :-) Of course, when they start imploding, you can gently remind them that they are free to prioritise any development they want in before any amount of bugs they have submitted. Back at the place we were using RT, we did that once or twice. Taught them to check what they asked for before saying 'it doesn't work right'. Wade. Save Fintlewoodlewix
Post #211,856 by drewk 6/20/05 10:37:53 PM Reply	The what doc? There are some process problems that can't be solved with better tools. I'd say most of them, actually. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]

Welcome to IWETHEY!