Guillame, I tried to be clear in my statement.
If the feature is working -- it is doing the job requested and generating the results expected -- it is doing the work that the developer designed it to do. If that implementation is inconsistent with a similar function in a different application, that is the consistency issue that was brought up on the thread. That means that different people designed the same function or a similar function in two different ways in two different products. Each may work, but they work differently. So, both are working as they were designed, but they are not working consistently across the two products which is less than optimal. If a feature is not working, it is broken. Whether that brokenness is because the design is bad or because a code error or because of the environment is a part of the detail. The feature is not doing the job. The cases that were brought up on the thread were all falling into the "working but working differently in different applications". That is where the RFE process is the way to get things worked on. BMC tries to bring these things together and is more successful in some areas than others. But, there are clearly areas where there is a lack of consistency. By the way, working as designed does not mean working "in the best way possible". It is simply working in the way the software was intended to work by the folks who implemented it. In discussing an issue with an end user, it doesn't change the fact that they are having an issue or would like to have something be different. But, the question is does the function do the job or not. Not is a bug, Yes but would like to be different about how it does it is an RFE. There are differences in how to go about addressing things in the two different categories. Now, if in your opinion, the operation is not doing the job that that feature should be doing, you should definitely feel justified in opening a support issue and working it through the support team. If the answer is that the product is doing the job it was designed to do, an enhancement request is possible. It would be like you wanting your car to go 500 miles per hour and you had a Ford Pinto from the 70s or 80s. You can say it is a bug that the car doesn't go 500 miles per hour when you press on the accelerator but the answer that the design limit is really 80 (or should it be 50) miles per hour is the limit is the design limit. It would very definitely be an enhancement request to ask for that car to go 500 miles per hour. On the other hand, if no matter what you do, it went only 5 miles per hour. The answer that it was how it was designed and it is limited to that is not an enhancement since it is not doing what its reasonable and expected function is -- to allow you to move around town reasonably. Is there a gray area around 70 mph or so? Sure there is. But that is for a subjective measure like this one. Most features have a more objective mearsure about what they are doing. Again, most of this thread was not about things not working but about not working in the same way in different applications. There was, in general, no disagreement about working. It was about doing it in the same way. Note that I have suggested filing BOTH types of things with BMC -- just one is a bug and the other an enhancement request. I also wanted to call out the fact that there is the enhancement request process that is available to all customers for any type of a change/extension/improvement to the product that they can think of. Our product management team does pay a lot of attention to these requests for future functionality. Doug Mueller ________________________________ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Friday, November 19, 2010 12:19 PM To: arslist@ARSLIST.ORG Subject: Re: "Working as designed" type defects ** Doug, thanks for your reply. The issue that I have with the "working as designed" label is that it implies that someone consciously made the decision for the design to be the way it is. That someone would be a product/application architect, a lead product/application developer, or lead business/system analyst. In any case, there is evidence of what the original intention was. If there is no evidence of the decision or intention of the design at fault, how can we classify this issue as working as designed? This is a problem of semantics.... Maybe it's better to classify this type of as "working as not expected" or something along those lines. BTW, when I convey to the customer the exact response from BMC support, the "working as designed", they are like WTF ?? You see what I mean....it's an corporate image/marketing issue here too. Guillaume ________________________________ From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on behalf of Mueller, Doug [doug_muel...@bmc.com] Sent: Friday, November 19, 2010 2:48 PM To: arslist@ARSLIST.ORG Subject: Re: "Working as designed" type defects ** Everyone, This topic has several different facets. I will try and address the different aspects I see. 1) Consistency of functionality across application is important. Absolutely. Everything from using consistent wording to consistent options, to consistent interaction. This should be true across all applications. Now, are the applications as good as they should be in some cases? No. Are they getting better with every release? Yes Is the goal to keep working on things so that there is more and more consistency of interaction? Yes There are times when there are changes to interaction that hit different applications at different times. That can introduce some temporary inconsistency until the other application(s) catch up with the new approach. But, those are a different type of issue. The things called out on this thread are about wording and operation and function for specific operations type consistency. This should be done better. 2) "As designed" response from support Well, there is always the balance of something being wrong or something working the way the product was intended. So, yes, even when there is some inconsistency of operation, if the product is working as it was intended (we will get to whether the intended was good or not in a bit), the answer you are getting is an accurate one. If something isn't working, then that is different. That may be a design error if it is not working. If something is not working, then you should push back on the "as designed" labelling. If it is working but is just not doing what you would like (or is not the same as some other application) this is not a design error -- it is doing what it was designed to do -- but it is something that could be done better to allow the solution as a whole to do better. What I have seen in this thread is that things are working but you would like them to be working differently so that the same things are the same way in different applications (and that is a justified desire) 3) The RFE (Request for Enhancement) process Now, if something is working and you want it to work differently, that is an enhancement request to the system. This is true whether it is just to work differently in isolation or whether it is to change it to work like it does somewhere else. This is no different than asking for a new capability of the system. Customers are always encouraged to submit enhancement requests to add to or alter the behavior of the system to do better for them. We have to treat RFEs differently than defects (bugs). A bug is not working and it should be fixed so that it works. No one will be disrupted by a feature that didn't work that now does. However an enhancement that adds functionality or changes how something interacts when it was working before can be disruptive and so needs to come in as a new feature in a release. I understand that there is subtlety here and that there are gray areas between things. And, you should feel free to have a discussion if something does fall into the gray area. But, most things will clearly fall on one side of the line or the other. There is a process for handling things on either side of the line to allow the best and most orderly response. Would it be better if there were no inconsistencies? You bet! But, they do creep in sometimes. We need to be diligent about working them out of the system. So, if you have had things that are "as designed" that are working but you wish they worked differently, please enter an RFE for the change to have it considered for a product enhancement. If you have things that are "as designed" but are NOT working, then it is fair to ask how something can be designed to not work! Your input is invaluable in helping to move the product forward. Input from customers has led to a number of significant cleanups in the applications in the past few releases and we are getting good response to the 7.6.3 release and another wave of consistency is coming in the next few releases. Also, some modularization going on inside the applications is making it more likely that consistent interaction will occur in many areas with more sharing of logic and interaction. This is a good discussion and it is important to keep BMC honest and not just hide behind an "as designed" shield. Please keep up the pressure. But, I hope this note has helped to explain a bit about why there are differences in something not working at all vs. not working best because another way is better and why they are different and why the difference is an important one in deciding how to respond to the report. I hope it also has helped encourage more submissions of RFEs to report consistency problems and ask for better in future releases. Doug Mueller ________________________________ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Wednesday, November 10, 2010 10:54 AM To: arslist@ARSLIST.ORG Subject: "Working as designed" type defects ** I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as "working as designed" The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab in the incident form When I raise these issues with BMC support, I get the reply that it's working as designed. Well the problem with that, is that customization is required to make functionality, and look and feel consistent. It seems to me that BMC should create a "Design Defect" classification in addition to the existing defect classification, which are essentially implementation defects. I mean why should I need to create an RFE for something that should work consistently in the first place? Seems like "Working As Designed" is simply an easy way out of the situation. Quality Assurance **should** catch these defects. Is this too much to ask? A defect is a defect because the customer perceives that as a defect, that should be the bottom line. This is not new functionality, only making the functionality and user interface work to the way it is expected. Thoughts? Guillaume _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
