>> You seem to be agreeing with the sentiment; since all software has bugs, why not be honest and say that it's a bug?<<
I agree it is a poor design to have a string too long error when you UPPER() a memo field. Calling it a bug is easy, but it might not fit the true definition of a bug. There are three parts to all alleged bug reports. One is the definition of a bug: something that works differently than the documented specifications. I believe we all have experienced customers reaction to software that is not working the way they want it to work. They automatically call it a bug. The reality of the matter is in many cases the code is developed to the specifications/requirements and something new was discovered, or a process in the business has changed, thus the enhancement request. The second is determining who pays for it. This is dependent on the contracts (original development, maintenance, etc), legal licenses and even public relations. A business problem. The third aspect is how one reacts to the alleged bug report. This is a business problem, not a technical problem and an aspect of our business where many companies fall down in my opinion. The larger the company the less agile they are. Small development shops typically turn on the dime and react with some change without arguing bug vs. ER. Larger companies with entrenched heavy development processes and methodologies often react slower. All of this impacts how a company determines if they call it a bug. Being cynical from time-to-time, I also believe development teams use the "by-design" excuse to brush off doing a change. I know VFP beta testers often pushed for some changes in the product based on testing new functionality. Sometimes the Fox Team listened and made difficult changes, and sometimes they were stubborn and we live with some not so fun designs. <g> In the case of the UPPER() on a memo field: I believe the developer who coded the UPPER() command should have looked at the spec and questioned if this made sense, and maybe they did. I am not sure of the deadline pressure and the impact it might have on other parts of the code in VFP. Maybe this happened, and maybe the trade-offs were worse or more costly. The decision might have been to go the way they did knowing the workaround is a simple one. So Ed, how do you approach this with the Dabo Frameworks and Tools? Do you call all bug reports or developer perceptions of incorrect behavior bugs? Rick White Light Computing, Inc. www.whitelightcomputing.com www.swfox.net www.rickschummer.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
