20080812

Top 10 Lame Developer Excuses

It's amazing the logical fallacies found in the excuses that are sometimes concocted by otherwise good and logical developers. The following are some of popular excuses I've been given for not fixing defects along with my response to the excuse.

10- It works on my machine. ->Are you going to ship your machine to the customer? The product needs to be installable and usable on other machines. This statement implies that there's something wrong with the tester or their configuration. Developers should not feel that this statement absolves them of any responsibility in helping to investigate and resolve the matter. Whatever the root cause of the problem is, it must be dealt with in some way (i.e. fix the bug, document the misunderstanding, make the install robust enough to recognize when prerequisites are not present, etc.). The fact that a tester encountered the problem means that customers WILL also encounter the problem. Customers can't write a bug or contact the developer when they encounter this problem, so the issue needs to be resolved so that either the user doesn't encounter the problem, or else the workaround is readily apparent and satisfactory to the customer.

9- Working as designed. ?You designed it to lose data and be unusable? A professional Quality Assurance person does not write frivolously bugs. Please try to trust us on this and we'll try our best to not ever give you any reasons not to trust us. If we didn't think that it was a violation of customer expectation for the product to behave in the way that we describe, we wouldn't have wasted our time writing up the defect report. Testers have a unique perspective into the product and the products use that Developers just can't see no matter how hard they try. It's just a result of the creation process, that you can't see it when your baby is ugly. When you have invested so much into making a product WORK, it's difficult to see all the ways that it might FAIL. Please trust us as your objective eyes on these things and don't give us a hard time about fixing them when we have spent the time and effort to identify them.

8- Have you tried it with * ? Where * is some other product or upgrade with which there is no reasonable cause to believe that it would effect the bad behavior that is being witnessed. ->This is just a stall to assign the bug to someone else because the developer doesn't feel that they have time to investigate the issue.
QA professionals are not developer helpers. Trust us that we have investigated the problem before writing the defect report, far enough to determine that the problem lies in your component.

7- There's nothing I can do to fix the problem, the problem is in our depended library X or product Y. ->By virtue of using someone elses libraries, we take on certain responsibilities for working gracefully around their warts. If you aren't willing to make some compromises, and go to certain lengths to minimize problems in a library or other software that you take advantage of in your development (which there will ALWAYS be in any software product), then you shouldn't be using it and you should write your own version. You can't just throw your hands up in dispare and blame the problem on someone elses software when issues are encountered. End users are not going to care that it's the fault of xyz library, all they care is that they got software from your company and it had this problem.

6- Is a user REALLY going to do ___? ->If I didn't think a user might do ___, I wouldn't have tried it and I wouldn't have written the bug. If that isn't enough to convince you, then listen to this, if there's one thing that is sure, it is that you CANNOT predict WHAT a user will do. In a universe of infinite possibility given enough time, users will eventually try everything that is possible. My experience has shown that they often try those far out actions that break the software, far more often than we expect.

5- (Security Issues) Why should we close the back door when the front door is wide open. I've actually heard the argument phrased with just that analogy. I think that the analogy holds true, because if you were attempting to secure your house with that attitude, you would never lock either door, because the other one would still be open. Regardless of what doors are open, we need to deal with each of them, as we encounter them. The fact that you can identify two problems should be more of a motivator to spend more effort on security, rather than an excuse to do nothing.
I do not expect to see bulletproof-secure software anytime within my lifetime. The problem is just too difficult with any non-trivial software products. The best game plan we have now and for the forseeable future is to perform due dillignece and make our software difficult enough to hack that the bad guys will take some other avenue (someone elses weak software, social engineering). In order to do this, you need to fix every security bug, to the best of your ability, whenever one is identified.

4- It's too late in the game to consider fixing that bug / Are you going to hold shipping for that. First of all, in most organizations it's not for a mere developer or tester to decide when the actual ship date will be. In a well managed software development process, there are many factors that go into determining the "readyness" of the software and many peoples input that goes into when it will ship. The findings and opinions of QA are one of the major determiners. Next, the issue needs to be dealt with in some way, even if it's merely to add it to the documentation or the list of known issues in the readme. Sometimes I've found that when forced to write the documentation about a bug that developers were "too busy to fix", they somehow find the time to fix it afterall, when they see how embarrassing it is to admit that the problem was allowed to exist in the product and they realize how long it takes to describe to a user the steps required to workaround that problem.

3- Can you identify any customers that are asking for this feature? ->In our company we do not make our living from writing contracted custom software. We write "Commercial Off the Shelf" software and as such, we try to anticipate customers needs and expectations and craft software that is most usable and most satisfactory to the most people. As soon as a customer has to come and ask us for a change in our software just so that they can use it, we have failed. It is NOT a normal flow of typical off-the-shelf software design.
If you still can't see the feature as anything but fluff, take it to the PM or to Support, someone who is even more in tune with the customers than QA and let them judiciate it. We should not have to wait for a customer to tell us what changes they need before we take actions to improve our software.

2- That's not a bug report, it's a feature request. ->Well, sometimes that can be debated, and sometimes you're right; occasionally we may slip up and try to sneak in new features under the guise that it's a bug. However, there are a couple of criteria (maxims) that we use when defining a bug that developers should be aware of before accusing testers of committing feature-creep-through-the-bug-list.
(1) A product must meet reasonable user expectation. If it doesn't do something that a reasonable user would naturally expect it to do, then, the fact that the feature is missing IS A BUG in the product. Even though the requested feature is something that you did not plan to include, it becomes a bug when customers assume that the product must be broken because this expected feature does not work (when every other software product does this). e.g. A text field that doesn't support copy/cut/paste. Auto-formatting SSN and phone number data. Sort by on primary data columns.
(2)

1- In all my __ years as a developer, I've never done it that way; I'll be damned if I'm going to start now. ->You WILL literally be damned if you refuse to adapt and improve, despite good sense, when the opportunity presents itself. Just because something is new to you does not mean that it is wrong. The software industry is still too new and things are still developing so rapidly, to take that kind of attitude before hearing something out is nothing short of presumptuous and pompous.

1 comment:

A4GPA said...

Excellent read that I can relate with all to clearly.