Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.

Hot answers tagged

463

This sounds absolutely nutty. It is expending a great deal of effort for very questionable benefit, and the practice seems based on some faulty premises: That QA won't work hard unless they know they are being tested every day (which cannot be good for morale) That there are not enough unintentionally introduced bugs in the software for QA to find That QA's ...


211

Well, based on what I've learned: It's not a school nor job interview; The testers are not children; It's not a game; It wastes company's money. The QA are not there only to find bugs but also to worry about how intuitive the system is, what is the learning curve for the user, usability, and accessibility in general. For example: "Is the system ugly?", "Is ...


189

You might not enter random values into fields of a web application, but there certainly people out there that do just that. Some people enter random by accident and others do it intentionally trying to break the application. In both cases, you don't want the application to crash or exhibit other unwanted behavior. For the first type of user, you don't want ...


104

Everybody Loves a Good Code Bash / WTF Session I am now worried that they will find bugs and blame me for the problems. Of course they will find bugs. You said it yourself: it's buggy (you already found bugs) and complex (it's very likely to have more). And yes they'll blame you for it. Because it's a large codebase and they will, over time, get ...


101

Never Assume Anything You cannot assume that any user will not do something "dumb" with your software by accident or on-purpose. Users can accidentally press the wrong button, the cat can walk over the keyboard, the system can malfunction, their computer can be hijacked by malicious software, etc. Furthermore, the user themselves may be malicious, ...


100

In layman's words: All programs can have bugs. Compilers are programs. Ergo, compilers can have bugs.


99

Bad idea. From the tester's point of view: "So they will test hard, because they know there are bugs present and not finding them might be considered as their incompetence." Basically the devs are booby-trapping the code. Few people like doing work which is ultimately pointless (because the bugs are known in advance) but which still affect how they are ...


93

Well, it's pretty simple: not all exceptions are bugs (and similarly, not all bugs manifest themselves as exceptions). As example of an exception that's not a bug, if you're reading a file from a USB drive and someone yanks the drive out of the socket. That's going to raise an exception (in most languages that support exceptions, that is). But it's not a ...


92

As Mikey mentioned, writing bugless code is not the goal. If that is what you are aiming for, then I have some very bad news for you. The key point is that you are vastly underestimating the complexity of software. First things first--You're ignoring the bigger picture of how your program runs. It does not run in isolation on a perfect system. Even the ...


80

Many answers have questioned your boss' methods/tactics/metrics/etc. But that is beside the point. Maybe you ARE slow. Every room of developpers has to have ONE that's slower than the rest, right? (That's just straight set-theory.) So let's assume that's you. The answer is, WHY are you slow? (Clearly that is the question you have to answer before you can ...


72

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it? You should give it your best effort. I know that sometimes there are conditions and environments that are so complex they can't be reproduced exactly, but you should certainly try if you can. If you never reproduced the bug and saw it for yourself, how can ...


69

It isn't that the goto is bad by itself. (After all, every jump instruction in a computer is a goto.) The problem is that there is a human style of programming that pre-dates structured programming, what could be called "flow-chart" programming. In flow-chart programming (which people of my generation learned, and was used for the Apollo moon program) you ...


64

Why is goto dangerous? goto doesn't cause instability by itself. Despite about 100,000 gotos, the Linux kernel is still a model of stability. goto by itself should not cause security vulnerabilities. In some languages however, mixing it with try/catch exception management blocks could lead to vulnerabilities as explained in this CERT recommendation. ...


60

There are several factors to take in account. To illustrate those points, I'll use an example of a field where a user should enter a percentage in a context of a quota defined for a specific task in terms of how much disk space the task could use. 0% means the task wouldn't be able to write anything to disk; 100% means the task could fill all the disk space. ...


58

To a software team, a bug is a software problem that needs to be fixed. Not all software problems need to be fixed. Updating software is expensive. Blizzard is telling you that your problem is an edge case. In other words, the edge case problem you discovered is not necessarily something they tested for or otherwise care to account for. Fixing the ...


58

I agree totally with the answers above as to why this is bad for motivation and just generally awful people management. However, there are probably sound technical reasons for not doing this as well: Just before the product goes to QA, the dev team adds some intentional bugs at random places in the code. They properly back up the original, working ...


57

Ideally, your software should be bug-free after each iteration, and fixing bugs should be part of each sprint, so the work required to fix bugs should be considered when assigning story points (i.e., a task that is more likely to produce bugs should have more story points assigned to it). In reality, however, bugs surface post-deployment all the time, no ...


56

Your boss may be correct: you may be "underperforming" (more on that in a minute). But it may not be just your level of competence that's to blame. I don't think it would be a reach to suggest forces outside your control are causing you stress, which is having a negative effect on your performance. Let's have a look at a few of the reasons your boss may now ...


53

Use the best tool for the job. Your version control system should be the best tool for recording when bugfixes and CRs are made: it automatically records the date and who made the change; it never forgets to add a message (if you've configured it to require commit messages); it never annotates the wrong line of code or accidentally deletes a comment. And ...


51

Yes You tend to find them more in languages that are actively being developed than in those that are relatively mature (and thus don't see a lot of change on a frequent basis). This is probably why most languages are released at various 'stages' of stability. A nightly build is far less likely to be stable than a release candidate, which itself is less ...


51

Edit I want to be clear that this answer is only talking about the concept of testing your QA process, and I'm not defending the specific methodology portrayed in the question. End Edit There is a valid reason to check if your testing/checking is actually working. Let me give you an example from manufacturing, but the principle is the same. It's typical ...


50

You're looking at it the wrong way. The test does not assert that code was removed. The test does assert a certain functionality. The test does not care about the amount of code required to make it pass, nor does it realize that you have removed some code. The value of having such a test is the very same as any other test that you create due to a bug: you ...


47

Is there some kind of cultivatable behaviour [...] that can help me at least reduce such kind of mistake Absolutely, it is called four-eyes-principle. If you had you shown your crontab entry to a second person (a person knowing cron, of course), chances are high the mistake would have been avoided. In programming, when it comes to this, people mostly ...


43

Triage comes from medical jargon - it is the process of prioritizing patient care. When used in the context of bugs it has a similar meaning - determining the priority of a fix. So, untriaged bugs are those that have not been assigned a priority yet.


43

You are absolutely right. Tracking changes is the job for your version control system. Every time you do a commit you should write a commit message explaining what was done, and referencing your bug-tracking system if this is a bug fix. Putting a comment in the code saying // begin fix for bug XXXXX on 10/9/2012 ... // end fix for bug XXXXX every time ...


41

Any number of reasons, including: Company had made commitment to user base to release at a particular time Bugs were not mission-critical, or even major New feature development was viewed as more important (whether correctly or not) To a small extent, this is like asking why you work as a programmer even though your programming knowledge isn't "complete". ...


39

TL;DR Assumption ("contract") of spurious wakeups is a sensible architectural decision made to allow for realistically robust implementations of thread sheduler. "Performance considerations" are irrelevant here, these are just misunderstanding that became widespread because of having stated in a published authoritative reference. (authoritative references ...


38

In my opinion, it doesn't make any sense to use C and want to avoid pointers. If you do so, then you'd better use another language. Pointers are unavoidable in C. This is what make C so powerfull and also what make C a pain in the ass sometime. C is meant to be used with pointers. Arrays are pointers, functions are pointers, memory allocation work through ...


38

Some work environments are unworkable. I've seen environments in which no one could survive (save for those who were in at the beginning) because so much was undocumented and questions were so vehemently discouraged. You really need to be honest with yourself regarding the expectations and the resources provided to help you to meet them. The problem may not ...


Only top voted, non community-wiki answers of a minimum length are eligible