×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Not All Bugs Are Random

timothy posted about a year ago | from the especially-not-bees dept.

Programming 165

CowboyRobot writes "Andrew Koenig at Dr. Dobb's argues that by looking at a program's structure — as opposed to only looking at output — we can sometimes predict circumstances in which it is particularly likely to fail. 'For example, any time a program decides to use one or two (or more) algorithms depending on an aspect of its input such as size, we should verify that it works properly as close as possible to the decision boundary on both sides. I've seen quite a few programs that impose arbitrary length limits on, say, the size of an input line or the length of a name. I've also seen far too many such programs that fail when they are presented with input that fits the limit exactly, or is one greater (or less) than the limit. If you know by inspecting the code what those limits are, it is much easier to test for cases near the limits.'"

Sorry! There are no comments related to the filter you selected.

The 80's called... (1)

Anonymous Coward | about a year ago | (#45813983)

They want their structured programming back...

Re:The 80's called... (0)

Anonymous Coward | about a year ago | (#45814049)

Use known-good libraries for everything you can. And always test for the null set. And if I could go back to the 80's, I'd do it in a heartbeat.

Obvious, but worth restating. (5, Informative)

Animats (122034) | about a year ago | (#45814005)

Fairly obvious statement, but one some newer programmers don't know. Koenig is talking about white-box testing, which is well understood.

Re:Obvious, but worth restating. (2)

deconfliction (3458895) | about a year ago | (#45814313)

Yes, we can retitle from "Not All Bugs Are Random" to "White-Box Testing Is A Real Thing"

Re:Obvious, but worth restating. (0)

Anonymous Coward | about a year ago | (#45814557)

Isn't this rudimentary CS101 intro stuff, or am I not understanding? For example, we need to worry about bounds testing input and not just leaving it up to the user to make the right input within the bounds and of the required type? I've learned bounds testing in even the most trivial of programming classes such as those Web 2.0 savvy interpreted language based intro courses.

Re:Obvious, but worth restating. (3, Interesting)

Anonymous Coward | about a year ago | (#45815103)

Yep, fairly obvious, but where I work there's this whole class of people who hide their incompetence behind the phrase "black box testing". At first I didn't understand why they insisted so much on doing black box testing, until one day we basically ran into what the article describes: a subsystem behaved poorly when one of its inputs was exactly on the boundary that that very subsystem had defined. In that case I saw the black box bunch crash and burn because they weren't able to even design a good test case, much less diagnose the cause of the problem.

To me Andrew's article basically says: if you want to be able to test code, you need to be able to read code. There is a whole breed of testers nowadays who are not able to do that.

Re:Obvious, but worth restating. (1)

plopez (54068) | about a year ago | (#45815511)

It is not the ob of black box testers to diagnose a problem, just report the failure. Hence the term "black box testing". They are not debuggers, but rather testers.

Re:Obvious, but worth restating. (4, Insightful)

uncqual (836337) | about a year ago | (#45815643)

I think in common usage, white box testing does not mean "debugging" or "diagnosing" the code - it means more like "testing that takes into account the internal design and implementation of the system under test rather than just the inputs and outputs".

There's a need for both types of testing. However, as long as white box testers don't get too wrapped up in the details to step back and view the system as a whole (as developers sometimes do), they can do both. But there are so few good testers in the business, you don't want to waste a good white box tester on developing black box tests.

Sadly, I suspect there are quite a few "average" developers out there who, had testing as a career been given more respect by the industry over the decades, would have been "great" white box testers. While there is significant overlap between the skills/personality attributes needed to be a great developer and those needed to be a great tester, there are a bunch of skills/personality attributes that are quite important in one field and not nearly as so in the other.

Is this news for anyone? (4, Insightful)

JeffOwl (2858633) | about a year ago | (#45814015)

We absolutely test all boundary conditions, on both sides. This is standard practice where I work, for just that reason.

Re:Is this news for anyone? (2)

Jane Q. Public (1010737) | about a year ago | (#45814145)

I don't even understand why this is being considered as news. If you don't know this already, you aren't the kind of programmer I've ever worked with.

Now... there are exceptions, too. For example if you know your input will always be less than X characters, you have only one boundary condition to check (no characters). If you know it will always be exactly Y characters you have no boundary conditions. On length, that is... using the same kind of example OP was using.

Re:Is this news for anyone? (1)

mvpll (542255) | about a year ago | (#45814327)

The whole point though is that you don't know your input. It should always be verified, no exceptions.

Re:Is this news for anyone? (1)

AuMatar (183847) | about a year ago | (#45814499)

Yes, but if its supposed to be verified by class/module A, which calls class/module B with clean input, then you don't need to test B with bad input, only A.

Re:Is this news for anyone? (2)

Cley Faye (1123605) | about a year ago | (#45814917)

Only if your very confident that B will never ever get it's input from anywhere else, or that if it happen, the "anywhere else" will also properly check it's input. Oh, and you should know for sure that A will never change and suddenly spit something that B won't accept. Better document your code, and hope that the future maintainer will actually read what you wrote.
In large, long-lived project, these assumptions are all hard to make.

Re: Is this news for anyone? (1)

Anonymous Coward | about a year ago | (#45815317)

though, it produces nice fireworks : http://en.wikipedia.org/wiki/Ariane_5#Notable_launches

Re:Is this news for anyone? (1)

plopez (54068) | about a year ago | (#45815521)

It's called integration testing. That is why unit tests are considered insufficient.

Re:Is this news for anyone? (1)

Sique (173459) | about a year ago | (#45814571)

I made it a routine to always check for all boundaries, even for those I believed to be covered already, and to throw an exception if the check fails. Even so often there are other undiscovered bugs that allow the function to be called with invalid data, or someone (often me) later reuses the function at another place and forgets the boundary checks.

Re:Is this news for anyone? (1)

ChunderDownunder (709234) | about a year ago | (#45815217)

A problem is, a fair % of programmers don't care for code maintenance and unit tests.

Documenting expected behaviour (e.g. javadoc) as to what exceptions will be thrown and writing unit tests to verify these trivial cases may seem pedantic to some.

Re:Is this news for anyone? (2, Insightful)

AmiMoJo (196126) | about a year ago | (#45815471)

Even if you think you "know" the input will always be a certain length or less than x characters you had better check it anyway and test what happens if it isn't. Otherwise one day you can guarantee it won't match your expectation.

About 60% of the random, occasional failure bugs I fix are people making these kinds of assumptions. Clocks never run backwards, sensors never fail, data never gets corrupted. In reality they do with alarming regularity.

Re:Is this news for anyone? (2)

uncqual (836337) | about a year ago | (#45815707)

In many cases, the "data corruption" case is just impractical to test for very well unless every datum has a hash or something associated with it or another copy exists and every function verifies the hashes or for both copies matching on entry.

Also, I've seen code that was so filled with validation of stuff that was already validated or produced by code we wrote that the bugs were mostly in the validation code not the logic associated with the core functionality.

There is a happy medium. It's important that an appropriate point on the continuum is picked based on the type of task (such as controlling the engines on a commercial jetliner engine vs. making a smart recommendation on what other articles the viewer might want to look at on a news site) and the implementation environment (such as assembly vs. Java). It's also important the everyone on the team grok where that appropriate point is for the task.

Re:Is this news for anyone? (1)

MikeBabcock (65886) | about a year ago | (#45815857)

Data corruption in my books should be handled by ending execution cleanly so as to not cause further problems.

Re:Is this news for anyone? (1)

LWATCDR (28044) | about a year ago | (#45815507)

That is what I thought as well.

This is not new (2, Informative)

Anonymous Coward | about a year ago | (#45814033)

http://en.wikipedia.org/wiki/Boundary-value_analysis

Bounds test? (4, Insightful)

jklovanc (1603149) | about a year ago | (#45814037)

Has testing degraded so far that people don't now what a bounds test is?

Re:Bounds test? (1)

msobkow (48369) | about a year ago | (#45814087)

You're more likely to hear "What's testing?" from a lot of programmers nowadays.

Testing was never even mentioned in my university courses, much less formalized.

Re:Bounds test? (1)

jklovanc (1603149) | about a year ago | (#45814405)

With Software Engineering courses more prevalent so is testing. What is a much bigger problem is coder schools who teach languages but not methods.

Re:Bounds test? (1)

dkf (304284) | about a year ago | (#45814591)

What is a much bigger problem is coder schools who teach languages but not methods.

They do teach methods! Classes and inheritance too...

Re:Bounds test? (1)

TheRealMindChild (743925) | about a year ago | (#45814763)

Bah, bullshit. They teach templates! Templates EVERYWHERE!

Re:Bounds test? (0)

Anonymous Coward | about a year ago | (#45814515)

Testing and error handling both, I wish had been covered more in classes.

Re:Bounds test? (1)

richlv (778496) | about a year ago | (#45814727)

unfortunately... this.
i'm not a programmer. i can't code anything. but when i see people wiring code and not bothering with any tests for it, i feel sad, because i am seeing way too many regressions in basic functionality that could be caught by a couple of simple tests.
in addition to passing these problems to users, it is also demotivating for other participants of a project that does not do proper test development. and i do not see a solution to this problem.

Re:Bounds test? (1)

Cley Faye (1123605) | about a year ago | (#45814923)

testing (noun): the action of releasing your program in the wild and cross fingers.

Re:Bounds test? (1)

penix1 (722987) | about a year ago | (#45815053)

support (verb): The act of charging for fixes to the code you didn't do testing on... It is a win-win for both sides...lol

Re:Bounds test? (1)

Anonymous Coward | about a year ago | (#45814259)

Has programming degraded so far that people don't know how to write code that won't fail a bounds test ?

Re:Bounds test? (0)

bob_jenkins (144606) | about a year ago | (#45814437)

Has testing degraded so far that people don't now what a bounds test is?

No, it's only slashdot which has degraded.

Who might know about this? (4, Interesting)

Anonymous Brave Guy (457657) | about a year ago | (#45814613)

That depends. If you're are a die-hard TDD fan, for example, then you'll be writing your (unit) tests before you necessarily know where any such boundaries are. Moreover, there is nothing inherent in that process to bring you back to add more tests later if boundaries arise or move during refactoring. It's not hard to imagine that a developer who leaves academia and moves straight into an industrial TDD shop might never have been exposed to competing ideas.

(I am not a die-hard TDD fan, and the practical usefulness of white box testing is one of the reasons for that, but I suspect many of us have met the kind of person I'm describing above.)

Re:Who might know about this? (0)

Anonymous Coward | about a year ago | (#45814953)

If you're are a die-hard TDD fan, for example, then you'll be writing your (unit) tests before you necessarily know where any such boundaries are.

What? You shouldn't be writing units tests until you know what your units are what what bounds they have. Test Driven Development, not Test Driven Design. Tests should very rarely change. In an unpractical setup, Tests should be made by the designers and the programmers should just be fleshing out the code.

You should not be doing almost any programming until the design is done. The one thing drilled into us in school was that making changes to design, after programming has started, is expensive. System Analysis and Design was a required course. There was a 3 day stretch where our teacher covered many different project failures and repeated many times about how important design is and how it should almost never change once programming starts. If it changes, you've failed to acquire the needed information from the client.

He also covered how the client doesn't know what they need, they only know what they want. It is the system architect to make sure the customer gets what they need. If it doesn't help the customer, YOU'VE FAILED. Ask good questions, understand their business inside and out, figure out what their real issue is.

Re:Who might know about this? (2)

Anonymous Brave Guy (457657) | about a year ago | (#45815359)

FWIW, what you're describing seems more practical to me. However, if you start from a position that "You should not be doing almost any programming until the design is done" then you're already a long way from how many TDDers practise and from the process that many who advocate TDD, including big name consultants and authors, describe.

Re:Bounds test? (1, Insightful)

girlintraining (1395911) | about a year ago | (#45814805)

Has testing degraded so far that people don't now what a bounds test is?

It's worse than that. They're using the word "random" to describe the behavior of a digitally based, computationally deterministic system. One. Zero. Off. On. Yes. No. This is all a computer understands. It cannot be "random" in any meaningful sense. It may be sufficiently complex so as to appear random, but it isn't. There's very little "random" about a computer, or a computer program. Every now and then a single bit error creeps into the I/O but the rate this occurs in computers not in space and thus subjected to extreme radiation is so low you could run most tests for many thousands of hours before encountering one.

Hell, creating randomness is so problematic in a computer that they've had to create specialized circuits to create entropy; And at that, it's still been shown to fall short of being random enough for some cryptographic algorithms... If creating entropy is this hard in a computer, then why do people suddenly point at the sky and say "It was teh randomz!" whenever it crashes? It wasn't random: Something caused it. It just may be beyond your ability or comprehension to know what it was, but it's a deterministic system. It did not just up and decide to fail because it felt like it.

Re:Bounds test? (0)

Anonymous Coward | about a year ago | (#45814909)

I blame windows. Windows taught people that 'computers crash, now and then.' They believe that is how computers are. They all crash occationally, don't they? (We who use the alternatives knows better, of course.) And so they don't blame their faulty code, probably just another computer glitch. Computers are random in their crashes - aren't they?

But glitches happen only due to sloppy programming and lack of testing. But that is not so obvious to the masses that grew up with windows - which were even worse before than it is today. They think computers crash, and it cannot really be prevented. It just happens. Similiar to how they occationally get a popup in the middle of their presentations. It just happens. A pro would turn off anything capable of popping up, but these people are so used that computers cannot be trusted...

Re:Bounds test? (0)

Anonymous Coward | about a year ago | (#45815071)

Something is considered random until it can be predicted. Of course it's not truly random. The word "random" also includes the definition of "odd, unusual, or unexpected."

Re:Bounds test? (0)

Anonymous Coward | about a year ago | (#45814889)

Each new generation of computer programmer is marked by a distinct lack of knowledge of classical software development problems that have already been solved. Degree programs tend not to cover this subject nearly as much as they should.

So, each generation also brings with it a bunch of people who mistakenly believe they have solved a novel problem, and nobly share their solution with the rest of the world. It isn't arrogance that motivates their sensationalism when they do so, it is just a combination of altruism and ignorance.

Re:Bounds test? (2)

Evil Pete (73279) | about a year ago | (#45815709)

I actually read the article. You know what it is? It is a simplified tutorial on white box testing for people who don't know, that is, amateur programmers. Yeah, that would have once been new and interesting to me, when I was learning to program. Not when I was doing it for a living though. Bad title and summary.

No shit Sherlock (4, Insightful)

cruachan (113813) | about a year ago | (#45814047)

You know, I remember writing test plans to to test input that were one below, at, and one above, some arbitrary limit when I was a trainee programmer coding up COBOL on mainframes back in the mid 80s.

How on earth does this drivel make it onto Slashdot? This is 30 year old news at least (which makes it straight out of the 17th C in internet years)

Re:No shit Sherlock (1)

geekoid (135745) | about a year ago | (#45814099)

Sadly, I still see developers not testing, and are practically afraid of writing test scripts.
It's not news to you or me, but these reminders are important for newer generations, especially to the 'I want to do it because it makes money and I couldn't care less about computers otherwise' programmers. AKA webmasters!

Re:No shit Sherlock (3, Insightful)

Tanuki64 (989726) | about a year ago | (#45814125)

Sadly, I still see developers not testing, and are practically afraid of writing test scripts.

Afraid? Less afraid than not paid for. 'Write your code correctly, then you don't need to test'. A bit simplified, but this is more or less what I heard more than once from a customer.

Re:No shit Sherlock (1)

aliquis (678370) | about a year ago | (#45814463)

"Pick your staff wisely and we're all sure we'll never make any mistakes!"

All software needs to be tested (0)

Anonymous Coward | about a year ago | (#45814841)

even the simplest of algorithms. No human has ever written 100% correct code 100% of the time.

Re:No shit Sherlock (0)

Anonymous Coward | about a year ago | (#45815313)

Should have responded with "If you didn't age, you wouldn't get old". Welcome to being human.

Re:No shit Sherlock (1)

ChunderDownunder (709234) | about a year ago | (#45815425)

In the case of test inputs, we're largely talking unit tests here, which form part of the code base to verify the functional code is correct. The 'customer' shouldn't have such fine grained control over the development process.

(As distinct from a black box tester who never looks at the source code etc)

As far as not using xUnit/TDD, that's often a generational thing where development practices stem from the previous millenium before Kent Beck and others popularised its widespread adoption. I've worked on several projects where senior managers were resistent to adopting unit tests but at the same time had serious problems with unmaintainable code and regressions etc, with many hours wasted sitting in front of a debugger trying to work out the cause of a coding flaw.

QA needs to be testing coders are poor QA / tester (1)

Joe_Dragon (2206452) | about a year ago | (#45814683)

QA needs to be testing coders are poor QA / testers and we need real live testers not some scripted system that can be coded to pass but still not be right and or well it passes but if any one looks at the out put they will say that does not look right.

Re:QA needs to be testing coders are poor QA / tes (0)

Anonymous Coward | about a year ago | (#45814843)

And QA doesn't usually understand what the designers intent is, so leaving it all to QA is a bad idea.

Re:QA needs to be testing coders are poor QA / tes (2)

plopez (54068) | about a year ago | (#45815595)

QA ignorance is not a bad thing. QA should not be working from designers POV but from a requirement/user story POV. If it does not satisfy the requirements or the user story, it is a bad design. Period. The less QA knows of the design the better.

Re:QA needs to be testing coders are poor QA / tes (1)

ChunderDownunder (709234) | about a year ago | (#45815497)

There's a scope for both and shared knowledge can be beneficial.

Part of the automated build process can be running QA scripts via a robot. e.g. QA person files a bug report with steps to reproduce the issue. A VNC script is attached to the bug report, which is then translated to, say, a junit script. Programmer inserts asserts in the junit code to verify expected conditions. In this way regressions are fewer and don't escape to the QA people in the first place.

Re:No shit Sherlock (1)

phantomfive (622387) | about a year ago | (#45814461)

The more interesting article is this one [drdobbs.com] : "Our survey of more than 3,000 developers and managers shows...salaries are on the rise once again"

Re:No shit Sherlock (0)

Anonymous Coward | about a year ago | (#45815179)

Don't worry... there is "immigration reform" on the horizon which takes off the number caps off of H-1Bs, so said salaries will be the same as the barista at Starbucks in no short order.

Of course not (1)

Billly Gates (198444) | about a year ago | (#45814053)

Those are features

. . . (redux) DUH (1)

Anonymous Coward | about a year ago | (#45814057)

And some people cannot be programmers, some cannot hammer a nail, and some cannot wear their wife's clothings in public. You aren't a real man until you can do all three.

Re:. . . (redux) DUH (1)

mooingyak (720677) | about a year ago | (#45815301)

And some people cannot be programmers, some cannot hammer a nail, and some cannot wear their wife's clothings in public. You aren't a real man until you can do all three.

... at once.

well no d'uh (0)

Anonymous Coward | about a year ago | (#45814079)

If this is a surprise to anyen writing code, you need to bone up on QA and failure modes.

Sherlock's theorem (0)

epine (68316) | about a year ago | (#45814097)

Many security bugs are really failures to implement correctly a requirement of the form "No matter what the input to this program is, it must not do X."

This is a special case of Sherlock's theorem:

Once you have eliminated the disallowed, whatever remains, however unintuitive, must be the robust.

It's far easier to debug a sin of omission than a sin of commission. If a piece of code never performs a disallowed function (e.g. leaking memory, failing to sanitize user input) then all failures that remain are sins of omission: the program doesn't actually transfer the file requested, out of excessive restraint on some edge case the programmer never even considered.

Well, the programmer needs to get in there and consider the omission in the harsh light of day. Then the specification document needs to be updated.

And questions need to be asked about the user environment when an edge case is tripped three years into a heavy use cycle.

The only way to achieve software up-front with no failure modes and no functional omissions is to massively gold-plate the validation process, and this rarely works anyway.

I'm never happier writing code than when I'm subtracting stupid.

Look at commit time stamp. (5, Insightful)

140Mandak262Jamuna (970587) | about a year ago | (#45814129)

Talking from personal experience, all the bugs I ever committed to production were coded in between 1 PM and 2 PM, my sleepiest time, when my stomach digesting the lunch was competing with the brain for blood supply.

If I am a columnist with some modest name recognition I could have converted this mildly amusing (to me at least) observation into a column. But alas, I am not one. So he gets to repeat the age old advice given by old Prof Mahabala, teaching Intro to Computing 201, (Fortran programming, in IBM 365/155 using punch cards no less ) back in 1980 into a column, and all I get to do is to bitch about it.

Re:Look at commit time stamp. (0)

Anonymous Coward | about a year ago | (#45814281)

Try a better lunch then. Something without bread, pasta, or cakey desserts.

Re:Look at commit time stamp. (0)

Anonymous Coward | about a year ago | (#45814401)

Because that will magically not require digestion anymore.

Re:Look at commit time stamp. (0)

Anonymous Coward | about a year ago | (#45814573)

Other than what the OP guessed at, you have no evidence that digestion is the problem.

Re:Look at commit time stamp. (0)

Anonymous Coward | about a year ago | (#45814985)

The company can always fix bugs later, I only have one life to live and I'm not skipping cakey desserts for lunch. I'm not skipping this either [youtube.com]

Re:Look at commit time stamp. (1)

jones_supa (887896) | about a year ago | (#45815865)

Something without bread, pasta, or cakey desserts.

Bread and pasta are good for maintaining a stable blood sugar, and the brain likes a stable blood sugar.

Well Duh (1)

MichaelSmith (789609) | about a year ago | (#45814149)

we can sometimes predict circumstances in which it is particularly likely to fail. 'For example, any time a program decides to use one or two (or more) algorithms depending on

If you have an MVC architecture with 10000 models, controllers and views; all of your domain data is stored as Object in maps, keyed with strings. If the keys for your middleware and your maps are built up on the fly and type casts are used at the point where your domain data is actually used, then you are probably going to have problems.

Oh and here's another good one: you have a module blah with an internal namespace com.company.blah but now you want a newblah so you copy blah and change two classes but leave the namespace the same then you get a bright idea: lets delete all the unchanged stuff from newblah and stick it into the classpath ahead of blah. The new module now inherits from the old one, right? Thats a brilliant idea, worthy of a genius. Oh yeah the classpath we customised isn't actually used to run the software, only to develop and test it.

Guess which prople make these bugs! (-1, Flamebait)

fisted (2295862) | about a year ago | (#45814155)

BUGS!

The same group of Prople behind

Chromebooks
KDBUS
Wayland
Gnome3
Pulseaudio
Systemd
Journald
Alienating Udev
Alienating 95% of their Userbase

(Sorry, I know i am overdoing it but this time it really, really is on spot!)

Evolution (1)

Anonymous Coward | about a year ago | (#45814163)

Has Dr. Dobbs discovered Software Engineering? They are only a few decades late.

You see this giant middle finger from QA (0)

Anonymous Coward | about a year ago | (#45814193)

The next time you excuse a bug as a corner case will be your last.

No bugs are random - computers are deterministic (0)

Anonymous Coward | about a year ago | (#45814267)

If computers can't make truly random numbers, then they can not make truly random bugs. This means that all bugs are deterministic. No bugs are actually random.

Re:No bugs are random - computers are deterministi (2)

msobkow (48369) | about a year ago | (#45814289)

Apparently you've never dealt with race conditions and multi-threaded code.

Re:No bugs are random - computers are deterministi (0)

Anonymous Coward | about a year ago | (#45814449)

Those aren't random, either; they just appear to be random.

Re:No bugs are random - computers are deterministi (1)

msobkow (48369) | about a year ago | (#45814519)

Let's see you force one to happen in the debugger, then.

Re:No bugs are random - computers are deterministi (0)

Anonymous Coward | about a year ago | (#45814927)

It is not random. If you have enough knowledge and the ability to comprehend that knowledge, you can predict what will happen. Nothing is random.

Re:No bugs are random - computers are deterministi (2)

PCM2 (4486) | about a year ago | (#45815141)

It is not random. If you have enough knowledge and the ability to comprehend that knowledge, you can predict what will happen. Nothing is random.

Sure, as long as you start a program and let it run all by itself without touching anything. As soon as you introduce human input, the system may still be deterministic, but the output of the program is in effect random because the behavior of the operator cannot be predicted. The kind of "knowledge and the ability to comprehend that knowledge" that you describe is known as omniscience, and most IDEs currently don't support it.

Re:No bugs are random - computers are deterministi (1)

msobkow (48369) | about a year ago | (#45815145)

Oh.

Excuse me.

"Stochastically Variable".

:P :P :P

Re:No bugs are random - computers are deterministi (1)

MikeBabcock (65886) | about a year ago | (#45815871)

When exactly will that bit be flipped by the stray subatomic particle hitting your PC from the sun?

Some bugs really are random.

Re:No bugs are random - computers are deterministi (2)

TechyImmigrant (175943) | about a year ago | (#45814723)

Not if the different threads are clocked from different PLLs.

Re:No bugs are random - computers are deterministi (1)

InsectOverlord (1758006) | about a year ago | (#45814503)

Good point, though it doesn't actually refute GP. Computers are deterministic*. On the other hand, programs, functions, etc may not be deterministic.

* Except devices specifically designed not to be deterministic, such as hardware random number generators that rely on quantum, electron phenomena, etc. Then again I'm not sure it is correct to call such devices computers.

Not the answer, different Q (1)

MonsterMasher (518641) | about a year ago | (#45814349)

In theory shouldn't any state change be checked for this interpolate continuity.
Do the sliding weight algo.. overlap N points in X, do both and adjust output as weighted ratio, mathematical discontinuity gone, all derivatives (within resolution of N) will be continuous. I've applied this and a simple 2 node neural-net device to make yes/no reply smooth (in respect to input.)
I've often wondered if this fuzzy logic device had a name.

The answer is Yes, of course those bugs must be hunted down and crushed into pulp and the trail backtracked and the colony attacked.
I agree! No Christmas bonus for Joe the janitor! that will teach 'em for making that error.

It's good to test the corner cases (3, Informative)

Black Parrot (19622) | about a year ago | (#45814423)

News at 11.

Re:It's good to test the corner cases (0)

Anonymous Coward | about a year ago | (#45815003)

You're going to make me wait until 11? Could someone post the spoiler and tell me if I should be testing the lazy susan I've got in the corner as well? I'm not sure if it's considered a corner case or just another cabinet.

Re:It's good to test the corner cases (1)

plopez (54068) | about a year ago | (#45815623)

Poster meant "3"

Are today's computer programmers devoid of the abi (0)

Anonymous Coward | about a year ago | (#45814429)

I had an interview a few years ago for a systems administrator position and knowledge of C was a requirement. I had programmed in C mostly as a hobby for several years prior but not during the most recent five years. The interviewer kept asking increasingly questions in hopes of tripping me. The interviewer eventually said I knew more about C than everyone of the people on his staff of highly experienced C programmers. I was even asked specifically about what test cases I would use given a certain short algorithm. It was bizarre how easy those test cases were to me but they astounded the interviewer.

'No' bugs are random (1)

Timmy D Programmer (704067) | about a year ago | (#45814447)

Short of hardware issues, no software bug is truly random, 'it just happens sometimes' = 'I lack the skill to troubleshoot this'

Re:'No' bugs are random (1)

Shinobi (19308) | about a year ago | (#45814527)

Apparently you've never used Perl.....

Look at the comments (2)

tomhath (637240) | about a year ago | (#45814589)

A study by the company I worked for a few years ago only found one thing that correlated with the number of bugs - the number of comments. It wasn't so much that the algorithm was complicated and needed explanation; more often it was just bad programmers tossing in a bunch of commented out print statements and comments that didn't accurately describe what the code was doing.

Back in my day... (1)

mjs0 (790641) | about a year ago | (#45814671)

Is there really anyone to whom this is not obvious?

When I started work, almost 30 years ago, in the Functional Verification team at IBM this was day one training.
"Test around the limits" (or bounds testing as it was known) was practically beaten into you.

what a juvenile story. (0)

Anonymous Coward | about a year ago | (#45814789)

if you are in 8th grade i give you a pass. but i suspect you suck.

What a useless research (0)

Anonymous Coward | about a year ago | (#45815047)

That's like a kindergarten level lesson on debugging.

no bugs are random (1)

wbr1 (2538558) | about a year ago | (#45815083)

In my mind all bugs arise from an unexpected set of conditions and/or poor coding. They may be unanticipated but that does not make them random.

Re:no bugs are random (1)

russotto (537200) | about a year ago | (#45815109)

Some bugs arise from such a complicated set of conditions that they appear to be random. These are the most interesting bugs, and the most infuriating.

Other bugs can even be truly random; a race condition that depends on whether one thread gets scheduled on a processor that's running just slightly faster (or slower) than another, for instance.

Computer theory (1)

mynamestolen (2566945) | about a year ago | (#45815105)

A program is an alogrithm or group of algorithms.

So surely we're talking about "correctness" of algorithms?

Isn't the best textboom on this by Dr Jeffrey Kingston, Algorithms and Data Structures: Design, Correctness, Analysis ??
http://www.goodreads.com/book/show/2682170-algorithms-and-data-structures [goodreads.com]

Have to agree with the above comments, but hey, slashdot is not what it used to be (they let me on for example).

I have to declare a possible conflcit of interest too; I know Kingston.

Re:Computer theory (1)

phantomfive (622387) | about a year ago | (#45815561)

Due to your suggestion, I am buying that book. Not sure if it's the best one, but I'm buying it. Thanks.

Coding 101 .. (0)

Anonymous Coward | about a year ago | (#45815209)

"any time a program decides to use one or two (or more) algorithms depending on an aspect of its input such as size, we should verify that it works properly as close as possible to the decision boundary on both sides"

If you haven't figured this out already, then you shouldn't be writing code ...

How is any bug random? (1)

HalAtWork (926717) | about a year ago | (#45815611)

Besides when it's caused by interference from background radiation?

Re:How is any bug random? (1)

mynamestolen (2566945) | about a year ago | (#45815763)

random is a silly concept too. It often means we don't know the reasons, so we call it random.

Adjectives and adverbs (0)

Anonymous Coward | about a year ago | (#45815701)

"that it works properly as close as possible"

The proper word is "closely".

When all words are equal there is no longer any communication. Unfortunately that day seems imminent.

Worst headline of 2013? (2)

khb (266593) | about a year ago | (#45815811)

Bugs are never RANDOM. Bugs are, by definition, an error (human blunder ... incorrect design, improper code, etc.)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?