6 ms·

It feels like a totally made up problem: "Here's a binary search algo description, implement it perfectly without testing". That's not even close to how devel

It feels like a totally made up problem: "Here's a binary search algo description, implement it perfectly without testing". That's not even close to how developers work, and he amplifies the disconnect with the real world by choosing a problem known for it's boundary and off-by-one risks.

DLarsen 17y ago
While this scenario may not allow developers to work like they normally do, I think the author's point is that a simple binary search isn't that complicated. A decent dev should still be able to a pretty good job despite those artificial constraints.
- brazzy 17y ago
  And the author is simply wrong about his point (if that is indeed his point). A binary search is that complicated. It just doesn't look like it until you've considered all the possible edge cases, and chances are that most "decent devs" will miss some and be part of the 90%.
  - MikeTaylor 17y ago
    Speaking as the author: his point, if any, is more along the lines that if we need a test-as-you-go approach to get something this simple to work, it's no wonder we have problems when we have to implement something that's actually complex. Also: no amount of test-drivenness can save you from just not grokking the problem (as Peter Norvig's Sudoku solver showed ... er, by counter-example.)
    - darthpanda 17y ago
      It's an interesting problem. People miss the point - that programmers are missing the basics and not really thinking the problems through, relying on our tools to think for us. Too many of us are hackers by day, myself included. A binary search just exposes the weakness.
    - 124816 17y ago
      I'm missing the back story -- tell me more about Peter Norvig's solver?
      - nicko 17y ago
        http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-work.html http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-w... http://norvig.com/sudoku.html http://norvig.com/sudoku.html
  - beagle3 17y ago
    If binary search is complicated, what is _simple_ by your standards?
    - DougBTX 17y ago
      FizzBuzz?
      - WildUtah 17y ago
        Which only 50% of us can solve correctly the first time?
  - dkarl 17y ago
    It isn't complicated compared to the convoluted stuff that programmers code to implement business "logic." The dirty secret of software development, however, is that 90% of industrial software developers can't handle abstraction at all and rely heavily on domain knowledge when coding anything. Programmers handle the cases that are normal for the problem domain, and QA tests the cases that are unusual in the domain context (and makes the programmer fix them.) The code will behave incorrectly on some edge cases, but if the developers and QA have covered the problem domain pretty well, it won't matter. First, most of the edge cases will never happen. Second, people get angry when software fails for no obvious reason, but they tend to be a lot more forgiving when software fails on inputs that are "freakish" or "wrong" in the domain context. Searching the widget catalog results in "500 Internal server error" when the widget catalog is empty? Well, duh! When should the widget catalog ever be empty?! The search page shows screwy results because someone entered an item with a negative price? Well, duh! Get that stupid item out of the catalog! Instead of thinking like a mathematician or a system designer in order to avoid mistakes, the typical development approach is to think like the customer so you only make mistakes that the customer can sympathize with.
    - weichi 17y ago
      I think there's a lot of truth here. I would also point out that for a lot of programming tasks, particularly in a corporate IT environment, "thinking like the customer" can be a good thing: it helps you make sure that you are building something that truly helps the customer do their job. The risk is that no matter how much "domain experience" you have, the customer has more, and you can fool yourself into thinking that you understand what they need better than they do.
  - tdmackey 17y ago
    If you read Bentley's original work that the article is based on then the point is exactly that even the most seemingly simple tasks like implementing a binary search are incredibly difficult if not near impossible to get "right."
  - dkarl 17y ago
    A binary search is that complicated. It just doesn't look like it until you've considered all the possible edge cases The fact that it's tractable to rigorously consider all the edge cases means it is ridiculously simple compared to common real-world programming tasks.
pavel_lishin 17y ago
> "Here's a description, implement it perfectly without testing". > That's not even close to how developers work You'd be surprised. Also, terrified.
- ams6110 17y ago
  My first job after college (1992) was with Andersen Consulting. All new staff consultants went to a "boot camp" to learn how to program (they hired many people who did not have a programming background, as well as some who did). They emphasized "desk checking" as part of the development process (for this reason: submitting a compile job on the mainframe might have a turnaround time of hours). So, one of the assignments was to write a program, and desk check it until you were confident that it would compile and run correctly on the first try. It was a one-chance, pass/fail assignment: it either worked, or there was a compile or runtime error.
  - count 17y ago
    Another reason is that by desk checking, you spend substantially more time working on the program - which means more billable time as a consultant.
joe_the_user 17y ago
Maybe it's not "real world" to have to implement a simple but serious algorithm in a few lines. Maybe in the "real world", the programming is just the simple gluing together of hard stuff like databases, compilers and operating system, since they have already been written. Once you have some bullet-proof method, it really is better to just be a consumer of it. There is still some hard stuff that needs to be done, though. I suspect that to do "the hard stuff" you need to be able to implement simple-but-serious algorithms in a few lines. This makes your overall code smaller, more readable and allows optimization for the particular cases you're working with.
- abstractbill 17y ago
  Maybe it's not "real world" to have to implement a simple but serious algorithm in a few lines. I don't think the parent was objecting to implementing a simple but serious algorithm in a few lines, but to doing so without performing any testing at all. There is still some hard stuff that needs to be done, though. Yes, and I'm pretty sure the people doing that hard stuff do some testing ;)
  - FutureNerd 17y ago
    Going back to Bentley, the point was not to code without testing but whether you could think through a small piece of code <i>before</i> testing. raganwald says, "It feels very retrograde to try to write the whole thing out and only then start thinking about [...] edge cases." Nobody said you had to write it before thinking about edge cases! The idea is to think about the edge cases and incorporate that thinking into the code before you actually test the code--whether you can be--actually whether you know the steps to be--that thorough in your head. One way to think about edge cases, of course, is to write the test code before the function. But after writing the tests, try writing the function correctly before testing it. Of course, one of the potential bugs in binary search doesn't occur to people before they write and then try it. And, that bug is hard to test for, ahem, don't want to explain why.

DLarsen 17y ago

While this scenario may not allow developers to work like they normally do, I think the author's point is that a simple binary search isn't that complicated. A decent dev should still be able to a pretty good job despite those artificial constraints.

brazzy 17y ago
And the author is simply wrong about his point (if that is indeed his point). A binary search is that complicated. It just doesn't look like it until you've considered all the possible edge cases, and chances are that most "decent devs" will miss some and be part of the 90%.
- MikeTaylor 17y ago
  Speaking as the author: his point, if any, is more along the lines that if we need a test-as-you-go approach to get something this simple to work, it's no wonder we have problems when we have to implement something that's actually complex. Also: no amount of test-drivenness can save you from just not grokking the problem (as Peter Norvig's Sudoku solver showed ... er, by counter-example.)
  - darthpanda 17y ago
    It's an interesting problem. People miss the point - that programmers are missing the basics and not really thinking the problems through, relying on our tools to think for us. Too many of us are hackers by day, myself included. A binary search just exposes the weakness.
  - 124816 17y ago
    I'm missing the back story -- tell me more about Peter Norvig's solver?
    - nicko 17y ago
      http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-work.html http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-w... http://norvig.com/sudoku.html http://norvig.com/sudoku.html
- beagle3 17y ago
  If binary search is complicated, what is _simple_ by your standards?
  - DougBTX 17y ago
    FizzBuzz?
    - WildUtah 17y ago
      Which only 50% of us can solve correctly the first time?
- dkarl 17y ago
  It isn't complicated compared to the convoluted stuff that programmers code to implement business "logic." The dirty secret of software development, however, is that 90% of industrial software developers can't handle abstraction at all and rely heavily on domain knowledge when coding anything. Programmers handle the cases that are normal for the problem domain, and QA tests the cases that are unusual in the domain context (and makes the programmer fix them.) The code will behave incorrectly on some edge cases, but if the developers and QA have covered the problem domain pretty well, it won't matter. First, most of the edge cases will never happen. Second, people get angry when software fails for no obvious reason, but they tend to be a lot more forgiving when software fails on inputs that are "freakish" or "wrong" in the domain context. Searching the widget catalog results in "500 Internal server error" when the widget catalog is empty? Well, duh! When should the widget catalog ever be empty?! The search page shows screwy results because someone entered an item with a negative price? Well, duh! Get that stupid item out of the catalog! Instead of thinking like a mathematician or a system designer in order to avoid mistakes, the typical development approach is to think like the customer so you only make mistakes that the customer can sympathize with.
  - weichi 17y ago
    I think there's a lot of truth here. I would also point out that for a lot of programming tasks, particularly in a corporate IT environment, "thinking like the customer" can be a good thing: it helps you make sure that you are building something that truly helps the customer do their job. The risk is that no matter how much "domain experience" you have, the customer has more, and you can fool yourself into thinking that you understand what they need better than they do.
- tdmackey 17y ago
  If you read Bentley's original work that the article is based on then the point is exactly that even the most seemingly simple tasks like implementing a binary search are incredibly difficult if not near impossible to get "right."
- dkarl 17y ago
  A binary search is that complicated. It just doesn't look like it until you've considered all the possible edge cases The fact that it's tractable to rigorously consider all the edge cases means it is ridiculously simple compared to common real-world programming tasks.

pavel_lishin 17y ago

> "Here's a description, implement it perfectly without testing". > That's not even close to how developers work You'd be surprised. Also, terrified.

ams6110 17y ago
My first job after college (1992) was with Andersen Consulting. All new staff consultants went to a "boot camp" to learn how to program (they hired many people who did not have a programming background, as well as some who did). They emphasized "desk checking" as part of the development process (for this reason: submitting a compile job on the mainframe might have a turnaround time of hours). So, one of the assignments was to write a program, and desk check it until you were confident that it would compile and run correctly on the first try. It was a one-chance, pass/fail assignment: it either worked, or there was a compile or runtime error.
- count 17y ago
  Another reason is that by desk checking, you spend substantially more time working on the program - which means more billable time as a consultant.

joe_the_user 17y ago

Maybe it's not "real world" to have to implement a simple but serious algorithm in a few lines. Maybe in the "real world", the programming is just the simple gluing together of hard stuff like databases, compilers and operating system, since they have already been written. Once you have some bullet-proof method, it really is better to just be a consumer of it. There is still some hard stuff that needs to be done, though. I suspect that to do "the hard stuff" you need to be able to implement simple-but-serious algorithms in a few lines. This makes your overall code smaller, more readable and allows optimization for the particular cases you're working with.

abstractbill 17y ago
Maybe it's not "real world" to have to implement a simple but serious algorithm in a few lines. I don't think the parent was objecting to implementing a simple but serious algorithm in a few lines, but to doing so without performing any testing at all. There is still some hard stuff that needs to be done, though. Yes, and I'm pretty sure the people doing that hard stuff do some testing ;)
- FutureNerd 17y ago
  Going back to Bentley, the point was not to code without testing but whether you could think through a small piece of code <i>before</i> testing. raganwald says, "It feels very retrograde to try to write the whole thing out and only then start thinking about [...] edge cases." Nobody said you had to write it before thinking about edge cases! The idea is to think about the edge cases and incorporate that thinking into the code before you actually test the code--whether you can be--actually whether you know the steps to be--that thorough in your head. One way to think about edge cases, of course, is to write the test code before the function. But after writing the tests, try writing the function correctly before testing it. Of course, one of the potential bugs in binary search doesn't occur to people before they write and then try it. And, that bug is hard to test for, ahem, don't want to explain why.