7 ms·

The Clean Coder: The Craftsman 62, The Dark Path.

85 points by puredanger 16y ago

mycroftiv 16y ago
Great article. I especially love the Heinlein quotation from The Moon is a Harsh Mistress, for hopefully obvious reasons. There is another similar quote from Heinlein's "Have Space Suit Will Travel" (written several years earlier) that is also good programming advice: "Daddy says that, in a dilemma, it is helpful to change any variable, then reexamine the problem."
moxiemk1 16y ago
Is this idea of a "Kata" commonplace? I rather like it...
- ramidarigaz 16y ago
  It comes from martial arts. I don't know which martial art specifically, but the word seems Japanese.
  - bennysaurus 16y ago
    A kata is a series of movements in a number of martial arts (also called 'forms' and a million other names depending on the style and origin). You practice the same movements over and over focusing on technique, balance and your state of mind. As referenced in in the story there are often a number of different types to choose from depending on what you are trying to achieve (relaxation, a specific move/technique, different fight situations). They also generally get harder and more refined as you go up belts/levels. Never heard of it before in the coding world though, might take it up, definitely looks useful!
- rbxbx 16y ago
  Yes yes. http://codekata.pragprog.com/2007/01/code_kata_backg.html#more http://codekata.pragprog.com/2007/01/code_kata_backg.html#mo... Old but good.
MaysonL 16y ago
In re word wrap, see: http://www.vpri.org/pdf/m2010002_lobjects.pdf http://www.vpri.org/pdf/m2010002_lobjects.pdf
edw519 16y ago
Funny how that which is right in front of your face can be so elusive. Are we so busy amongst the trees that we can't see the forest? One of my mentors once gave me a list a obvious things to check when stuff doesn't work. Funny, years later I still need this list: 1. It worked. No one touched it but you. It doesn't work. It's probably something you did. 2. It worked. You made one change. It doesn't work. It's probably the change you made. 3. It worked. You promoted it. It doesn't work. Your testing environment probably isn't the same as your production environment. 4. It worked for these 10 cases. It didn't work for the 11th case. It was probably never right in the first place. 5. It worked perfectly for 10 years. Today it didn't work. Something probably changed.
- deleted 16y ago
  [deleted]
deleted 16y ago
[deleted]
Cushman 16y ago
This article sort of makes me wonder about the value of test-driven development. Just glancing at the problem, I came up in my head with what I thought was a simple algorithm to solve it— which turned out to be pretty much the same as the final implementation in the article. It made it a bit torturous to have to keep reading the author beating his head against his tests instead of just asking himself, what's the simplest way to solve this? Maybe I'm missing the purpose of the exercise? I do see the value of behavioral testing in general. I just have to wonder if we're taking it too far in saying that even if you can see the answer to the problem, you're not allowed to write it down yet.
- ekidd 16y ago
  I'm a raving TDD/BDD fanatic, and this kata still makes me cringe a little. At least they finally converge on a plausible-looking solution. Sadly, some TDD katas on the web turn into train wrecks. See Ron Jeffries' Sudoku solver, for example: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... If I were implementing this algorithm using TDD, I'd first write down a bunch of test cases, and then try the obvious algorithm. If that worked, I'd test a few more corner cases. There's really no reason why you have to blindly stagger through the design space when the algorithm is obvious.
  - nostrademons 16y ago
    I think this is a problem with a lot of methodologies, in that they often obscure that the point is to write good software. If you can write good software without following the methodology, do that. All these techniques - agile, scrum, stand-up meetings, CRC cards, TDD, pair programming, code review, unit tests - are just tools at your disposal to make writing the program go smoother. Google's methodology for writing quality software is basically: 1. Hire good people. 2. Let them do what they need to to get the product out the door. This seems to have been adopted by FaceBook as well. I wish more companies would consider it instead of adopting the snake oil that a bunch of consultancies peddle.
    - 16y ago
nkurz 16y ago
OK, someone just give me the answer: is this designed as an example of what one should do, or is it a parable of what not to do? I started reading it earlier today, and gave up once I hit the sexist tone. Then seeing the comments here, I realized that it was just parodying Heinlein. Cuz it's not really sexist if you're quoting, right? Anyway, given all the upvotes I thought there must be something to the article. In the same way, at the start I thought that ridiculously verbose ad-hoc testing functions were also a parody. Surely his point was going to be that your time is better spent writing a testing framework that reads from a text file rather than writing a 95% duplicate function for each test? But then I got to the end, and I lost my faith. Is he mocking Heinlein or just channeling some unrepentant 60's SciFi sexism? And is he really suggesting that this is really a good way to write software?
- deleted 16y ago
  [deleted]
- bennysaurus 16y ago
  Lots of ways to interpret it, but stripping back the story, it's showing a technique to sharpen your skills and looking at a problem in different ways. As you say there are definitely better ways to test the actual wrapper class in a real life situation, but showing the test suites one by one gives the reader a chance to see how the narrator approaches the problem and various situations are word-wrap class would face. If you were set your own 'katas' and reproduce similar code from scratch or a framework, I can see it helping some people look at various problems in different ways and look objectively at how they solve them. Every person has their own methods all the same.
- mquander 16y ago
  I don't think it's a parody, because I can see what he's getting at. If the programmer had written the "simpler" test first, he might have stumbled upon the algorithm as illustrated without the false starts at the beginning, and then it would seem like more of a successful approach. Then again, I'm not sure how you're supposed to know which tests are the magic ones which will guide you to a solution, and the author conveniently trails off without telling us. (I'm also not sure what happened to first sitting down with a pen and paper and figuring out the algorithm, instead of praying to the TDD gods that you might magically stub your toe on it.)
michael_dorfman 16y ago
I'm a bit surprised to find that Uncle Bob is still writing installments of "Software Craftsman"-- I can't even remember how many different defunct software development magazines I used to follow the series in...
edanm 16y ago
I've never used TDD, and this definitely hasn't convinced me I should do so. I knew the solution as soon as I sat down and thought for 1 minute to myself - it's a pretty obvious algorithm. I just don't see how coding test-first helps in this case. It certainly didn't help in the story told, but I don't know how it can help in the real world.
- gaius 16y ago
  Uncle Bob is a well-known snake-oil, ermm I mean methodology salesman. That's all you need to know about this article.
  - hello_moto 16y ago
    He's trying to make our industry a little bit better one programmer at a time. Why throw stones at him? He believes in TDD. He's passionate about it and he shares his knowledge. If he makes money from this (which probably not his end-goal when he decided to learn and share his knowledge) then more power to him. Not everybody should make money from being a "hardcore (but cowboy) coder".
- drblast 16y ago
  What struck me is the guy was coding to pass his tests only, not thinking about the right way to code the algorithm. It's like coding by taking stabs in the dark until every degenerate case you thought of is handled correctly. There's still no understanding of the problem or even a hope of a "proof" that what you did was correct. Is this the future of software development? No wonder software is crap.
  - demallien 16y ago
    Yup. That's why I prefer only writing a test for the most nominal case at first, and then code that solution. I don't write any more tests until I have a bug in the system, and I feel the need to convince myself that the subsytem is behvaing the way I think it does. Basically test-writing becomes a debugging tool like putting in trace, breakpoints or watchpoints. You have doubts about a part of your system, so write a test to confirm that it does what you think it does. I find that by the time a module is reasonably mature, I have enough tests to make a fairly solid test rig. I also don't waste time writing tests for trivial degenerate cases that I can handle correctly in my code without even having to think about it.
jedbrown 16y ago
Sure uses a lot of stack.
wrs 16y ago
"Hi Alphonse. What's up?" The gruff voice of Bob, Jerry's manager (or "master", as he called him), came from behind them. "Oh, I see Jerry is showing you how to generate unnecessary String garbage and stack overflow exceptions. Wow, and in a simple word wrap function, too. Nice job, Jerry." Alphonse was confused. "Bob, how do you know that? We didn't write tests for those things. I don't even know if you can write tests for them." Bob looked at Alphonse with a sad expression. "Jerry, could I see you in my office--sorry, my 'dojo'--for a minute?"
- gaius 16y ago
  I'd have a great deal of difficulty in taking anyone seriously who called their office their "dojo". Or liked their direct reports to call them "master".
  - adn37 16y ago
    I have no problem calling Sensei a particular great coder/architect. I even used to do it for the fun of it. But when it comes down to management asymmetric relationships, I do my best to avoid biasing it more ("master"). Could be a great way to practice office theater, though.
    - gaius 16y ago
      It's not healthy to consider oneself subordinate to ones manager. You're peers with different roles, that's all. He's more about the what, you're more about the how.
  - wrs 16y ago
    Jerry is the one making up all this martial arts nonsense...Bob is just humoring him.
- kleiba 16y ago
  Also, too bad Alphonse didn't include a test such as: @Test public void stringContainsNewline() throws Exception { assertThat(wrap("ab\ncd e", 4), equalTo("ab\ncd e")); }
pvg 16y ago
A far more entertaining (it's funny because it's true!) variant is http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
Tichy 16y ago
Somehow that way of coding makes my head hurt.
adn37 16y ago
My martial-arts self died a little at the Kata word used for such things.
- dagw 16y ago
  Let's see. A short, pointless, repetitive exercise, done for its own sake and with very little practical application or relevance. Sounds like a kata to me.
nathanielksmith 16y ago
I feel pain when I see the word "recurse."
ohyes 16y ago
"A kata is just a simple program that you write over and over again as a way to practice." Sounds like a waste of time. I can see how it would be good for a physical activity where you need to train your muscle memory, but I can just as easily train my programming reflexes by doing my job or working on open source. There are so many things you could program, why make up things to program that don't need to be programmed? Does anyone actually do this? If so, can you describe the ways in which it actually helps you get better.
chewbranca 16y ago
While the final recursive solution is nice, it is trivial to split the string on spaces and recombine inserting newlines when the current line overflows. This is not as elegant of a solution, but it took far less time to build that than it did to read the article.

85 points by puredanger 16y ago

Great article. I especially love the Heinlein quotation from The Moon is a Harsh Mistress, for hopefully obvious reasons. There is another similar quote from Heinlein's "Have Space Suit Will Travel" (written several years earlier) that is also good programming advice: "Daddy says that, in a dilemma, it is helpful to change any variable, then reexamine the problem."

moxiemk1 16y ago

Is this idea of a "Kata" commonplace? I rather like it...

ramidarigaz 16y ago
It comes from martial arts. I don't know which martial art specifically, but the word seems Japanese.
- bennysaurus 16y ago
  A kata is a series of movements in a number of martial arts (also called 'forms' and a million other names depending on the style and origin). You practice the same movements over and over focusing on technique, balance and your state of mind. As referenced in in the story there are often a number of different types to choose from depending on what you are trying to achieve (relaxation, a specific move/technique, different fight situations). They also generally get harder and more refined as you go up belts/levels. Never heard of it before in the coding world though, might take it up, definitely looks useful!
rbxbx 16y ago
Yes yes. http://codekata.pragprog.com/2007/01/code_kata_backg.html#more http://codekata.pragprog.com/2007/01/code_kata_backg.html#mo... Old but good.

MaysonL 16y ago

In re word wrap, see: http://www.vpri.org/pdf/m2010002_lobjects.pdf http://www.vpri.org/pdf/m2010002_lobjects.pdf

edw519 16y ago

Funny how that which is right in front of your face can be so elusive. Are we so busy amongst the trees that we can't see the forest? One of my mentors once gave me a list a obvious things to check when stuff doesn't work. Funny, years later I still need this list: 1. It worked. No one touched it but you. It doesn't work. It's probably something you did. 2. It worked. You made one change. It doesn't work. It's probably the change you made. 3. It worked. You promoted it. It doesn't work. Your testing environment probably isn't the same as your production environment. 4. It worked for these 10 cases. It didn't work for the 11th case. It was probably never right in the first place. 5. It worked perfectly for 10 years. Today it didn't work. Something probably changed.

deleted 16y ago
[deleted]

deleted 16y ago

[deleted]

Cushman 16y ago

This article sort of makes me wonder about the value of test-driven development. Just glancing at the problem, I came up in my head with what I thought was a simple algorithm to solve it— which turned out to be pretty much the same as the final implementation in the article. It made it a bit torturous to have to keep reading the author beating his head against his tests instead of just asking himself, what's the simplest way to solve this? Maybe I'm missing the purpose of the exercise? I do see the value of behavioral testing in general. I just have to wonder if we're taking it too far in saying that even if you can see the answer to the problem, you're not allowed to write it down yet.

ekidd 16y ago
I'm a raving TDD/BDD fanatic, and this kata still makes me cringe a little. At least they finally converge on a plausible-looking solution. Sadly, some TDD katas on the web turn into train wrecks. See Ron Jeffries' Sudoku solver, for example: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... If I were implementing this algorithm using TDD, I'd first write down a bunch of test cases, and then try the obvious algorithm. If that worked, I'd test a few more corner cases. There's really no reason why you have to blindly stagger through the design space when the algorithm is obvious.
- nostrademons 16y ago
  I think this is a problem with a lot of methodologies, in that they often obscure that the point is to write good software. If you can write good software without following the methodology, do that. All these techniques - agile, scrum, stand-up meetings, CRC cards, TDD, pair programming, code review, unit tests - are just tools at your disposal to make writing the program go smoother. Google's methodology for writing quality software is basically: 1. Hire good people. 2. Let them do what they need to to get the product out the door. This seems to have been adopted by FaceBook as well. I wish more companies would consider it instead of adopting the snake oil that a bunch of consultancies peddle.
  - 16y ago

nkurz 16y ago

OK, someone just give me the answer: is this designed as an example of what one should do, or is it a parable of what not to do? I started reading it earlier today, and gave up once I hit the sexist tone. Then seeing the comments here, I realized that it was just parodying Heinlein. Cuz it's not really sexist if you're quoting, right? Anyway, given all the upvotes I thought there must be something to the article. In the same way, at the start I thought that ridiculously verbose ad-hoc testing functions were also a parody. Surely his point was going to be that your time is better spent writing a testing framework that reads from a text file rather than writing a 95% duplicate function for each test? But then I got to the end, and I lost my faith. Is he mocking Heinlein or just channeling some unrepentant 60's SciFi sexism? And is he really suggesting that this is really a good way to write software?

deleted 16y ago
[deleted]
bennysaurus 16y ago
Lots of ways to interpret it, but stripping back the story, it's showing a technique to sharpen your skills and looking at a problem in different ways. As you say there are definitely better ways to test the actual wrapper class in a real life situation, but showing the test suites one by one gives the reader a chance to see how the narrator approaches the problem and various situations are word-wrap class would face. If you were set your own 'katas' and reproduce similar code from scratch or a framework, I can see it helping some people look at various problems in different ways and look objectively at how they solve them. Every person has their own methods all the same.
mquander 16y ago
I don't think it's a parody, because I can see what he's getting at. If the programmer had written the "simpler" test first, he might have stumbled upon the algorithm as illustrated without the false starts at the beginning, and then it would seem like more of a successful approach. Then again, I'm not sure how you're supposed to know which tests are the magic ones which will guide you to a solution, and the author conveniently trails off without telling us. (I'm also not sure what happened to first sitting down with a pen and paper and figuring out the algorithm, instead of praying to the TDD gods that you might magically stub your toe on it.)

michael_dorfman 16y ago

I'm a bit surprised to find that Uncle Bob is still writing installments of "Software Craftsman"-- I can't even remember how many different defunct software development magazines I used to follow the series in...

edanm 16y ago

I've never used TDD, and this definitely hasn't convinced me I should do so. I knew the solution as soon as I sat down and thought for 1 minute to myself - it's a pretty obvious algorithm. I just don't see how coding test-first helps in this case. It certainly didn't help in the story told, but I don't know how it can help in the real world.

gaius 16y ago
Uncle Bob is a well-known snake-oil, ermm I mean methodology salesman. That's all you need to know about this article.
- hello_moto 16y ago
  He's trying to make our industry a little bit better one programmer at a time. Why throw stones at him? He believes in TDD. He's passionate about it and he shares his knowledge. If he makes money from this (which probably not his end-goal when he decided to learn and share his knowledge) then more power to him. Not everybody should make money from being a "hardcore (but cowboy) coder".
drblast 16y ago
What struck me is the guy was coding to pass his tests only, not thinking about the right way to code the algorithm. It's like coding by taking stabs in the dark until every degenerate case you thought of is handled correctly. There's still no understanding of the problem or even a hope of a "proof" that what you did was correct. Is this the future of software development? No wonder software is crap.
- demallien 16y ago
  Yup. That's why I prefer only writing a test for the most nominal case at first, and then code that solution. I don't write any more tests until I have a bug in the system, and I feel the need to convince myself that the subsytem is behvaing the way I think it does. Basically test-writing becomes a debugging tool like putting in trace, breakpoints or watchpoints. You have doubts about a part of your system, so write a test to confirm that it does what you think it does. I find that by the time a module is reasonably mature, I have enough tests to make a fairly solid test rig. I also don't waste time writing tests for trivial degenerate cases that I can handle correctly in my code without even having to think about it.

jedbrown 16y ago

Sure uses a lot of stack.

wrs 16y ago

"Hi Alphonse. What's up?" The gruff voice of Bob, Jerry's manager (or "master", as he called him), came from behind them. "Oh, I see Jerry is showing you how to generate unnecessary String garbage and stack overflow exceptions. Wow, and in a simple word wrap function, too. Nice job, Jerry." Alphonse was confused. "Bob, how do you know that? We didn't write tests for those things. I don't even know if you can write tests for them." Bob looked at Alphonse with a sad expression. "Jerry, could I see you in my office--sorry, my 'dojo'--for a minute?"

gaius 16y ago
I'd have a great deal of difficulty in taking anyone seriously who called their office their "dojo". Or liked their direct reports to call them "master".
- adn37 16y ago
  I have no problem calling Sensei a particular great coder/architect. I even used to do it for the fun of it. But when it comes down to management asymmetric relationships, I do my best to avoid biasing it more ("master"). Could be a great way to practice office theater, though.
  - gaius 16y ago
    It's not healthy to consider oneself subordinate to ones manager. You're peers with different roles, that's all. He's more about the what, you're more about the how.
- wrs 16y ago
  Jerry is the one making up all this martial arts nonsense...Bob is just humoring him.
kleiba 16y ago
Also, too bad Alphonse didn't include a test such as: @Test public void stringContainsNewline() throws Exception { assertThat(wrap("ab\ncd e", 4), equalTo("ab\ncd e")); }

pvg 16y ago

A far more entertaining (it's funny because it's true!) variant is http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...

Tichy 16y ago

Somehow that way of coding makes my head hurt.

adn37 16y ago

My martial-arts self died a little at the Kata word used for such things.

dagw 16y ago
Let's see. A short, pointless, repetitive exercise, done for its own sake and with very little practical application or relevance. Sounds like a kata to me.

nathanielksmith 16y ago

I feel pain when I see the word "recurse."

ohyes 16y ago

"A kata is just a simple program that you write over and over again as a way to practice." Sounds like a waste of time. I can see how it would be good for a physical activity where you need to train your muscle memory, but I can just as easily train my programming reflexes by doing my job or working on open source. There are so many things you could program, why make up things to program that don't need to be programmed? Does anyone actually do this? If so, can you describe the ways in which it actually helps you get better.

chewbranca 16y ago

While the final recursive solution is nice, it is trivial to split the string on spaces and recombine inserting newlines when the current line overflows. This is not as elegant of a solution, but it took far less time to build that than it did to read the article.