Tag Info

Hot answers tagged

139

Sounds like it would do more harm than good. Ignoring for a moment whether it is fair for a manager to do that, let's look at the logistics... Problem 1: Are all bugs created equal? Developer 1 introduces a bug: Erases all customer data and curses at them. Developer 2 introduces two bugs: Form labels are not left aligned, and the calendaring feature is off ...


102

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 ...


98

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


92

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 ...


86

IPV4 only networking code. The time hasn't come for most people yet, but the idea of IPV4 only networking will become obsolete.


76

They get tested thoroughly via usage by thousands or even millions of developers over time. Also, the problem to be solved is well defined (by a very detailed technical specification). And the nature of the task lends itself easily to unit / system tests. I.e. it is basically translating textual input in a very specific format to output in another kind of ...


76

Many localization issues fit this pattern: a generation ago, programmers assumed all characters can be represented with an 8 bit data type a generation ago, programmers assumed every kind of text should be read left-to-right, top-down a generation ago, programmers assumed the field separator in a CSV file is always the comma character , (No, it really ...


73

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 ...


71

It was actually in a 3rd party image viewer sub-component of our application. We found that there were 2-3 of the users of our application would frequently have the image viewer component throw an exception and die horribly. However, we had dozens of other users who never saw the issue despite using the application for the same task for most of the work ...


64

In my experience the pattern is this: System works, often for years An error is reported The developer investigates the error and finds a bit of code which seems to be completely flawed and declares that it "could never have worked" The bug gets fixed and the legend of the code that could never have worked (but did for years) grows Let's be logical here. ...


60

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 ...


60

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 ...


57

Reproducing a bug that rarely happens. Especially when coping with multithreading.


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 ...


54

I once had to work on a Classic ASP application where the lead developer had proudly claimed to have rewritten the underlying data-access components in .NET. Technically, he wasn't lying, and the code was littered with statements like: set query = "EXEC spDeleteCompany " & intCompanyId arrResult = ...


54

Is it a bad sign? I think it's a warning that's worth looking into, but I also think it's bound to happen. When people submit any kind of feedback to me, I try to filter it into three buckets: Bugs Feature Requests Mis-communication Bugs Bugs are when something obviously doesn't work the way you would expect, nor the way the user would expect. Like, ...


53

Avoid fancy coding. The more complicated the code, the more likely there's bugs. Usually on modern systems, clearly written code will be fast and small enough. Use available libraries. The easiest way to not have bugs writing a utility routine is to not write it. Learn a few formal techniques for the more complicated stuff. If there's complicated ...


50

The more powerful the type system of the language, the more bugs will be caught at the compile time itself. The following figure compares some of the well known programming languages in terms of the power, simplicity, and safety of their type systems. [ Source ]


50

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 ...


47

Programmers are notorious for optimizing what managers start rewarding. If you reward LOC, then you get lots of whitespace to pad out the lines of code metric. If you try to punish by bug count, you will start getting into wars where the developers claim that X is not their bug (the bug is in the compiler or API or just somewhere else) - and the bug filed ...


47

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

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 ...


43

The scariest code I've ever dealt with would probably be the code for a .NET 2.0 application: Well, there was the main form, which contains 27,591 lines, 4,754 of which is the auto-generated Windows Form designer code. In other words, over 20,000 lines of actual code written by the original developer, in one file, in one project, for a single form. And ...


42

I'll suggest a new one, Sleeper Cell. Seems apt to me. A sleeper cell refers to a cell, or isolated grouping of sleeper agents that belong to an intelligence network or organization. The cell "sleeps" (lies dormant) inside a target population until it receives orders or decides to act


40

A bug without context is not a bug, it's a fluke. The problem could be your code, it could be a third party library, it could be the hardware, or it could be solar radiation causing a single bit to flip on it's own. If you can't reproduce it with at least some regularity (even if only "it happens once every 10 or 20 times I do X"), it's not much better than ...


40

Here a list of Unusual software bugs exceptionally difficult to understand and repair: Bohrbug - Manifests itself consistently under a well-defined (but possibly unknown) set of conditions Mandelbug - Its causes are so complex that its behaviour appears chaotic or even non-deterministic. Heisenbug - Disappears or alters its characteristics when an attempt ...


40

It means there are really no error-free programs. A profound quote about ways to avoid errors with an error itself is parody.


40

Validators for domain names making wrong assumptions like: TLD is 2-3 characters long (not true since 2001); domain names and TLDs contain only US-ASCII characters (not true since January 2010);


40

Build an SSCCE (short, self contained, correct example). If the bug disappears when you remove some of the extra details for the SSCCE, then you found it. Otherwise you will have an SSCCE that you give or post that ideally eliminates the code that you are concerned about sharing.



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