Generalization, Abstraction, Taxonomy, Perspective, Opinions

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!