2 ms·

Of course you shouldn't just write the whole thing out and then start to think about the errors. And these days most code is developed incrementally. However,

Of course you shouldn't just write the whole thing out and then start to think about the errors. And these days most code is developed incrementally. However, not all code is developed incrementally, testing miniscule details on the way. Some code is written perhaps 20 lines at a time before testing. Binary search is only about 20 lines, my implementation is significantly less. So there are cases where 20 lines are written, then tested. The thought experiment here is to assume that this is one of those cases, one instance of which there are probably 5 or 10 in a moderate sized project. Places where people perhaps got a little lazy, it was obviously easy, or didn't bother following the full TDD. And as I say in a comment elsewhere, only 1 in 3 of the people who tested passed my test suite. Your point is valid, but misses some of the point of the article, and the exercise.

raganwald 17y ago
Well I wouldn't say the point of the exercise and my point are entirely disconnected, perhaps the point of the exercise is to remind people that the size of their increments is really driven by the complexity of the test suite and not by the expected length of the code. It's an idea I explored very poorly in an old blog post: http://github.com/raganwald/homoiconic/blob/master/2009-06-02/functional_complexity.md#readme http://github.com/raganwald/homoiconic/blob/master/2009-06-0...
hammerdr 17y ago
I think that writing a binary search algorithm without tests is evidence of a poor programmer (or, at the very least, poor programming practice; there are talented programmers out there that can just sling code). This is a difficult and, as the sibling comment noted, error prone algorithm. These types of problems are poster children for TDD and testing. There is under 20 lines of code but several ways to make logical errors. If we test drive the code, we can ensure that the algorithm performs exactly how we want it to.
- queensnake 17y ago
  I hate to break it to you but you'll fail interviews at the better companies with that attitude(1). No matter much support your work methods give you, you have to be able to hold and work with a few moving parts in your head at once, correctly. (1) Don't ask me how I know :)
  - hammerdr 17y ago
    In my experience, this isn't true. In fact, my 'attitude' of approaching work like a craftsman has served me very well in job interviews (even landing me opportunities at pie-in-the-sky type of jobs).

raganwald 17y ago

Well I wouldn't say the point of the exercise and my point are entirely disconnected, perhaps the point of the exercise is to remind people that the size of their increments is really driven by the complexity of the test suite and not by the expected length of the code. It's an idea I explored very poorly in an old blog post: http://github.com/raganwald/homoiconic/blob/master/2009-06-02/functional_complexity.md#readme http://github.com/raganwald/homoiconic/blob/master/2009-06-0...

hammerdr 17y ago

I think that writing a binary search algorithm without tests is evidence of a poor programmer (or, at the very least, poor programming practice; there are talented programmers out there that can just sling code). This is a difficult and, as the sibling comment noted, error prone algorithm. These types of problems are poster children for TDD and testing. There is under 20 lines of code but several ways to make logical errors. If we test drive the code, we can ensure that the algorithm performs exactly how we want it to.

queensnake 17y ago
I hate to break it to you but you'll fail interviews at the better companies with that attitude(1). No matter much support your work methods give you, you have to be able to hold and work with a few moving parts in your head at once, correctly. (1) Don't ask me how I know :)
- hammerdr 17y ago
  In my experience, this isn't true. In fact, my 'attitude' of approaching work like a craftsman has served me very well in job interviews (even landing me opportunities at pie-in-the-sky type of jobs).