Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Not All Bugs Are Random

timothy posted about 10 months 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.'"

cancel ×

165 comments

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

The 80's called... (1)

Anonymous Coward | about 10 months ago | (#45813983)

They want their structured programming back...

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

Anonymous Coward | about 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months ago | (#45815507)

That is what I thought as well.

This is not new (2, Informative)

Anonymous Coward | about 10 months ago | (#45814033)

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

Bounds test? (4, Insightful)

jklovanc (1603149) | about 10 months ago | (#45814037)

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

Re:Bounds test? (1)

msobkow (48369) | about 10 months 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 10 months 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 10 months 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 10 months ago | (#45814763)

Bah, bullshit. They teach templates! Templates EVERYWHERE!

Re:Bounds test? (0)

Anonymous Coward | about 10 months ago | (#45814515)

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

Re:Bounds test? (1)

richlv (778496) | about 10 months 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 10 months ago | (#45814923)

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

Re:Bounds test? (1)

penix1 (722987) | about 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months ago | (#45814053)

Those are features

. . . (redux) DUH (1)

Anonymous Coward | about 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months ago | (#45814281)

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

Re:Look at commit time stamp. (0)

Anonymous Coward | about 10 months ago | (#45814401)

Because that will magically not require digestion anymore.

Re:Look at commit time stamp. (0)

Anonymous Coward | about 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months ago | (#45815145)

Oh.

Excuse me.

"Stochastically Variable".

:P :P :P

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

MikeBabcock (65886) | about 10 months 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 10 months ago | (#45814723)

Not if the different threads are clocked from different PLLs.

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

InsectOverlord (1758006) | about 10 months 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 10 months 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 10 months ago | (#45814423)

News at 11.

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

Anonymous Coward | about 10 months 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 10 months ago | (#45815623)

Poster meant "3"

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

Anonymous Coward | about 10 months 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 10 months 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 10 months ago | (#45814527)

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

Look at the comments (2)

tomhath (637240) | about 10 months 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 10 months 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 10 months 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 10 months ago | (#45815047)

That's like a kindergarten level lesson on debugging.

no bugs are random (1)

wbr1 (2538558) | about 10 months 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 10 months 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 10 months 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 10 months 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 10 months 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 10 months ago | (#45815611)

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

Re:How is any bug random? (1)

mynamestolen (2566945) | about 10 months 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 10 months 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 10 months 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?