tag:blogger.com,1999:blog-8993901435573921786.post2023625757669657527..comments2024-02-15T01:12:13.681-08:00Comments on Pin Dancing: Sudoku in Coders At workRavihttp://www.blogger.com/profile/03630087669712445498noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-8993901435573921786.post-6227846724762864562012-01-30T13:34:33.848-08:002012-01-30T13:34:33.848-08:00I prefer not to boil this down to religion, I actu...I prefer not to boil this down to religion, I actually agree with some of Marcel's more concrete point (i.e. read, think then agree), though I ultimately do not agree the usefulness of TDD.<br /><br />On the other hand, he is also a jerk, as shown in his earlier empty/taunting comments.Bill Yanghttps://www.blogger.com/profile/11095977392691545904noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-11853313672075675742010-03-26T14:24:51.472-07:002010-03-26T14:24:51.472-07:00You've pretty much hit the nail on the head :)...You've pretty much hit the nail on the head :) "It is hypocrisy of the first order that people who don't know how to program well advise the rest of us how to." - that is so true !Aniruddhahttps://www.blogger.com/profile/10439371861332281905noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-22074131655877272432009-12-26T00:46:40.274-08:002009-12-26T00:46:40.274-08:00oops!I meant to say that I did not know that it wa...oops!I meant to say that I did not know that it was this blog then in my previous comment. ate one word.Jasshttps://www.blogger.com/profile/18124047732843355736noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-5518403120810076952009-12-25T23:53:55.041-08:002009-12-25T23:53:55.041-08:00I read that interview between norvig and seibel ab...I read that interview between norvig and seibel about a couple months back. Did know that, this was the blog that he referred to then. Chanced on your blog today. Lot of interesting posts you got there ravi! Looks like I have a lot of reading to do today. My google reader is already overflowing ;)Jasshttps://www.blogger.com/profile/18124047732843355736noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-44918185660134623442009-10-08T08:33:51.026-07:002009-10-08T08:33:51.026-07:00"Marcel: I really don't care to measure d..."Marcel: I really don't care to measure dick sizes or anything."<br /><br />Ravi: To compare dick sizes you should have one. In this context ,"dicks" = superior code. You don't have any. Hard to compare sizes of non existent dicks.<br /><br />"<br /><br /><br />Zing! Pwned!<br /><br />Ravi, you are completely right. Thanking you for taking on this cult. Agilists are the Scientologists of programming. <br /><br />Hey agilistas, Before telling other people how to code or design, how about showing some results of your superior approaches tools?<br /><br />less gab. more code.<br /><br />Otherwise, please, please just SHUT up.<br /><br /><br />SHUT UP!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-47930291667793367522009-10-08T07:23:44.187-07:002009-10-08T07:23:44.187-07:00Vlad,
as always we largely agree and any differe...Vlad,<br /><br /> as always we largely agree and any differences are ones of emphases and phrasing.<br /><br />Regds,Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-60220781999529930622009-10-08T07:19:14.884-07:002009-10-08T07:19:14.884-07:00"But... I don't know [Peter Norvig] from ..."But... I don't know [Peter Norvig] from Joe."<br /><br />Heh I figured :-) And it shows in your ramblings.<br /><br />"I only care about stuff that makes sense to me, no matter who is saying it. So "Peter Norvig says X" is absolutely meaningless to me... "<br /><br />As do I. Replace Peter Norvig with Jeffries or Marcel.<br /><br />The difference is, Peter Norvig's competence is obvious in the superior *code he wrote *.<br /><br />Jeffries' stupidity is obvious in the *code* he wrote with TDD.<br /><br />So who should we listen to again? :-P You agile morons are hilarious.<br /><br />Your inanities are rejected by programmers because they don't make sense and are not valid and because you don't have the superior code to validate your supposed superior design methodology, not on the basis of your level of fame.<br /><br />You have a *claim* about having a superior dessign method in TDD. and you preach it endlessly, including on other people's blogs. You just don't have the code to back it up. All hat No cattle.<br /><br />"On the other hand, most people prefer not to think. Thinking is hard, and they would get it wrong anyway. Instead, they cheat - they pick someone famous who agrees with their preconceptions and say "look, this guy says X, he's more famous than you, so there".<br />"<br /><br /><br />This is EXACTLY how agile preachers like you think , as you show just below. This is why your leaders are people who can't code for nuts (Ward Cunnigahm excepted but then he doesn't go around preaching TDD).<br /><br /><br />"Oh well. I have code samples on my blog; not developed using TDD unfortunately (I really need to do that sometime)"<br /><br /><br />In other words you don't have any TDD'd code good enough to show that you are a programmer we should listen to, *yet* you preach the virtues of TDD to me on *my* blog comments.<br /><br />That was *the point*.<br /><br />I worked on TDD'd projects for years at ThoughtWorks with some of the best agilists in the world - the quiet, "focus on business value and code quality" type of people, not loudmouths like messrs Jeffries and Bob Martin). So when I dismiss TDD as a design method, at least I know what I speak about.<br /><br />See the difference?<br /><br />Till you have code at the level of people in CaW, (again this is about code not fame) don't bother telling us that we should listen to you vs them.<br /><br />"I really don't care to measure dick sizes or anything."<br /><br />To compare dick sizes you should have one. In this context ,"dicks" = superior code. You don't have any. Hard to compare sizes of non existent dicks.<br /><br />"and may the best programmers win."<br /><br />Programming is not a contest, but yeah whatever. Some sanity at last.<br /><br />Goodbye!Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-46938151359920743282009-10-08T06:59:52.863-07:002009-10-08T06:59:52.863-07:00Vlad
"don't want to belabour my point too...Vlad<br />"don't want to belabour my point too much since it's tangential to the main thrust of your argument about design, wherein I think we largely agree anyway."<br /><br />I agree we are largely in harmony.<br /><br />"I can change any aspect of the plot, the names of the characters, the order of the chapters, etc. The worse thing that that could happen is it may be a little confusing for some readers. If I make changes that people don't like, well, it's a matter of taste, but you can't say it "doesn't work""<br /><br /><br />Huh but that *is* exactly how stories "work".<br /><br />As you said, let us not go down this rabbit hole?<br /><br />"On the other hand, it is in indeed *possible* to make such continual updates to "live" software in a way that isn't really possible for physical structures."<br /><br />You can have updates to music or a play too.And you ignore Sw on a CD or a chip and restrict yourself to server side sw. You can *update* at the risk of something breaking. True for everything.<br /><br /><br />"that is why the design of software generally should to be fairly abstract and loosely coupled, and that's also why having a reasonable suite of automated tests is pretty much non-negotiable for any real piece of software that's out there."<br /><br />Ahh but no one is arguing automated tests are bad. We are talking about using TDD( which is NOT having a suite of automated tests to assure regression) as a design method.Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-53139945393446519052009-10-08T06:43:40.495-07:002009-10-08T06:43:40.495-07:00I don't want to belabour my point too much sin...I don't want to belabour my point too much since it's tangential to the main thrust of your argument about design, wherein I think we largely agree anyway. Still, I am tempted to clarify a bit:<br /><br />My sense is that software is rather special in the particular way it is expected to be soft, and this does indeed have ramifications vis. ongoing design. To compare I offer an example of something much softer and something much harder, both being qualitatively different (imo):<br /><br />Let's say I publish an online book, or a blog. I can change the contents, and *publish* those contents live, at any time. If it's a story, I can change any aspect of the plot, the names of the characters, the order of the chapters, etc. The worse thing that that could happen is it may be a little confusing for some readers. If I make changes that people don't like, well, it's a matter of taste, but you can't say it "doesn't work" in any sense that is completely objective.<br /><br />Now for something truly as hard as a rock: Once you've actually put up a skyscraper, you are basically stuck with what you've got. Even minor changes, like say adding one extra story, become prohibitively expensive. Making ongoing changes to a building that is already "in production" is very difficult.<br /><br />Software occupies a weird middle ground. Once software has been published, either as a CD or as a live Web application, the same code is expected to undergo continual change over the lifetime of that piece of software. On one hand, making even a seemingly innocuous change to a piece of software can *break* that software. On the other hand, it is in indeed *possible* to make such continual updates to "live" software in a way that isn't really possible for physical structures. <br /><br />Without getting into TDD at all, that is why the design of software generally should to be fairly abstract and loosely coupled, and that's also why having a reasonable suite of automated tests is pretty much non-negotiable for any real piece of software that's out there.Nestedhttps://www.blogger.com/profile/09680919094932667147noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-36336415334934352432009-10-08T06:35:20.211-07:002009-10-08T06:35:20.211-07:00About two years ago, I exchanged a couple of email...About two years ago, I exchanged a couple of emails with Mr. Norvig - as it happens, about that exact Sudoku program. I wrote one, and mine was in a compiled language (Delphi) and it was SLOWER than the times he reported for a Python program. I couldn't figure out the reason - the solver had a similar architecture, I had optimizations on, so he assumed he was using better hardware. He's a nice guy. But... I don't know him from Joe.<br /><br />The problem with a lot of people is that they worship authority. For various reasons (like an incredible ego), I don't. I only care about stuff that makes sense <b>to me</b>, no matter who is saying it. So "Peter Norvig says X" is absolutely meaningless to me... and I can't argue with it, because it's not an argument; it's a childish, emotional statement.<br /><br />Misko Hevery's writings make a lot of sense to me. So do those of Daniel Cazzulino. When Misko says "don't use the <b>new</b> keyword because you're mixing stuff that shouldn't be mixed" - I read, I think, and I agree. When he says "here's how I know TDD is good: because it enables me to do X and Y" - I read, I think, and I ultimately agree.<br /><br />On the other hand, most people prefer not to think. Thinking is hard, and they would get it wrong anyway. Instead, they cheat - they pick someone famous who agrees with their preconceptions and say "look, this guy says X, he's more famous than you, so there". That, for them, is enough. I'd have assumed that only americans do that (I indicate my reasoning on my blog), but apparently it's more widespread than this.<br /><br />Oh well. I have code samples on my blog; not developed using TDD unfortunately (I really need to do that sometime), but I'm pretty happy with where I am as a programmer. So don't worry - I really don't care to measure dick sizes or anything. Go and program with my blessings, and may the best programmers win.Marcelhttps://www.blogger.com/profile/13951354231483245521noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-68750145036315091392009-10-08T06:15:52.648-07:002009-10-08T06:15:52.648-07:00Vlad,
"too soft to matter" is a value j...Vlad,<br /> "too soft to matter" is a value judgment. <br /><br />Also I wasn't talking about music on a CD (then we'll have to talk about a sw binary on a CD) , but music as in an orchestra.<br /><br /> "You can change a piece of music as much as you want to as you're working on it without any repercussions."<br /><br /><br />Do you play any instrument or sing? The above is completely wrong. The "repercussion" in music is cacophony and people throwing eggs at you.<br /><br /> You can change a piece of sw as much as you want, if you now how. . A partuclar change might sound cacophonous in music or give odd results with sw. Changes have consequences.<br /><br /> "Once a piece of music is published/recorded, that's it, just as with a novel or a skyscraper"<br /><br />Ditto SW burned onto a chip or CD.<br /><br />Anyway you are on teh wrong track. My point wasn't to say music was exactly equivalent to sw in all aspects. No two things are exactly equivalent.<br /><br /> Marcel was ignoring the main point I made("Design" in not unque to sw and is distinct from an embodiment of the design. Nor is the "softness" of sw *unique*.)<br /><br />Naivete is different from wilful foolishness.Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-59421249536570223682009-10-08T05:43:31.546-07:002009-10-08T05:43:31.546-07:00"I'm waiting eagerly for Marcel's nex..."I'm waiting eagerly for Marcel's next comment."<br /><br />Heh. I am sure he is off somewhere using his superior TDD based design skillz to build a world beating product to show us unbelievers the efficiacy of his religion.<br /><br />I am sick of stupid agile zealots who preach at others. They tell others how to write code but never write any great code themselves.Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-39483382803657704122009-10-08T05:28:26.774-07:002009-10-08T05:28:26.774-07:00I'm waiting eagerly for Marcel's next comm...I'm waiting eagerly for Marcel's next comment. For the comedy.Peter Thomashttps://www.blogger.com/profile/12601547950877794218noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-51994961147314524452009-10-07T01:56:29.063-07:002009-10-07T01:56:29.063-07:00Ahh more foolishness from the agilist hordes.
&qu...Ahh more foolishness from the agilist hordes.<br /><br />"Hint: we don't use cement in software; we keep it SOFT. "<br /><br />Look I *said* Martin Fowler said this much better than you.<br /><br />"That's what makes it design instead of rocks."<br /><br />heh Music is even "softer" than software. No capable musician has a problem distinguishing design performance. No playwright has a problem distinguishing plotting and performance. <br /><br />Instead of blindly repeating what Fowler said, do some thinking for yourself.<br /><br />Instead of blathering about how superior your "design method" is on other people's blogs, why don't use that superior design method to write some great code.<br /><br />Here'e the challenge.<br /><br />Show us. Don't make sales pitches.<br /><br />Show. Superior. Code.<br /><br />THEN preach.<br /><br />Simple Idea isn't it?<br /><br />When people using TDD as "design method" write great codebases/software products at the level of the people interviewed in CaW, THEN tell us how you did it.<br /><br />Till then take your religious blabbering elsewhere. While your "masters" stumble around for days on simple problems with your "superior design method" you have zero credibility.Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-76559929599070181742009-10-07T01:41:26.376-07:002009-10-07T01:41:26.376-07:00The building is the plan...
Ahh... here's the...<i>The building is the plan...</i><br /><br />Ahh... here's the problem. You're building hardware. I thought we were discussing software. Hint: we don't use cement in software; we keep it SOFT. We keep changing it. That's what makes it design instead of rocks.<br /><br />Oh well. You'll learn. Oh, and you might want to google the phrase before long... there's a tiny chance you might learn something.Marcelhttps://www.blogger.com/profile/13951354231483245521noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-15570218974950411802009-10-07T01:37:29.191-07:002009-10-07T01:37:29.191-07:00"the code is the design"
Sure. The buil..."the code is the design"<br /><br />Sure. The building is the plan, the play is the script and the music is the sheet of paper with the funny squiggles on it ;-)<br /><br />The code *embodies* the design. It isn't the same thing. Anybody who thinks they are the same hasn't been writing code long enough.<br /><br /><br />Better people than you (e.g Martin Fowler) have made an argument for this notion. And it is still not very credible.<br /><br />It would be a valid argument if its practitioners could *show* us examples of superior code they wrote/shipped this way. <br /><br />The book "Coders At Work" (which is the topic of this post btw ;-) )<br />deals with people who *have* programmed great works in software. And not *one* of them thinks TDD is a method of *designing* code (vs building a regression suite, or trapping an error and so on). And in the lines quoted above, Peter Norvig explicitly doesn't agree with this "extreme notion"<br /><br />Allow me to quote (since you obviously haven't *read* the post)<br /><br />"This extreme approach of saying, “Well, the first thing you do is write a test that says I get the right answer at the end,” and then you run it and see that it fails, and then you say, “What do I need next?”—that doesn’t seem like the right way to design something to me."<br /><br /><br />On matters of *programming* Peter Norvig is much more credible than the agile gaggle.<br /><br /><br /><br />The people who promote TDD as a design method on the other hand have ZERO intersection with great programmers and have nothing *to show*. <br /><br />They just *talk* about how cool their "design method" is. When it comes to actual coding with TDD they end up like Mr Jeffries with his Sudoku solver. That Mr Jeffries and other fanatics like Bob Martin are leading lights for this "design method" and accepted as such by its practitioners is all that needs to be said.<br /><br /><br />When people start thinking coding and designing are identical you get horror shows (again like Jeffries's Sudoku Solver).<br /><br /><br />Nice Try anyway.<br /><br />Look if you "design" your code with TDD and the people who pay you are foolish enough to let you get away with it,I don't care. Go right ahead. Don't come here and preach your kool aid religion.<br /><br />I'll happily live in the "Stone Ages" of programming.Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-42911673995042056542009-10-07T01:09:27.839-07:002009-10-07T01:09:27.839-07:00This is perfectly correct and on the dot. I call i...<i>This is perfectly correct and on the dot. I call it Tests Driven Coding.</i><br /><br />Good. The next thing you need to understand is "the code is the design". That makes "test driven coding" a form of design - coding <b>is</b> design. Once you grok that, you can understand the meaning of TDD :)Marcelhttps://www.blogger.com/profile/13951354231483245521noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-9599205398182861492009-09-21T21:03:24.910-07:002009-09-21T21:03:24.910-07:00Vlad,
I don't have much time but this will hav...Vlad,<br />I don't have much time but this will have to be short.<br /><br />It seems you are on a mission to defend TDD as a "design" method by changing the meaning of "design" to fit! (which is fine by me of course!)<br /><br />I agree with much of what you say, for example,<br /><br />"TDD is a technique to help you write better code. "<br /><br />This is perfectly correct and on the dot. I call it Tests Driven Coding. I even use it sometimes when using an OO/imperative language(vs something like Haskell).<br /><br />But what you call "hill climbing"( where you say TDD helps) sounds suspiciously like what Mr Jeffris does, blundering around thrashing.<br /><br />My (and Norvig's) point is that even when you do this, you have to have some elementary knowledge of things that were discovered in the sixties. Things like dynamic programming. This will ensure that you have to "hill climb" only in situations that really call for it.<br /><br />And when you have to do *real* hill climbing , when you are trying to do domething which doesn't have any literature supporting it, , *TDD* is still of little use. (If you think otherwise, please point me at a research paper where someone actually discovered a new algorithm using TDD)<br /><br /><br />You'd do better thinking, forming a hypotheses, writing a quick prototype, observing results and forumatng the next hypothesis. TDD is incidental to this process.<br /><br />Once your understanding has been refined, you can then doa TDD for the final implementation.<br /><br />So there are two kinds of "hill climbing". One is when you are in a genuinely new situation where you are doing research on the frontiers of human knowledge. Here, sure you do "hill climbing", but you start the climb equipped with the best mental tools you know. Nobody parachutes into unexplored woods without shoes and a compass and nothing to eat or drink starts blundering around and calls it "exploring".<br /><br />Jeffries "hill climbing" (the second kind) is that of someone who is clueless about the fundamentals of his craft (and no algorithms are not something exotic and "edgy"). Basic algorithms should be understood by *every* programmer *before* he sets out to do "TDD" or "RUP" or whatever.<br /><br />A decent "structure of the code" (which TDD provides, if done right) is of no use if the person writing the code is an idiot without knowledge of the fundamentals of the craft, which in my opinion Mr Jeffries(along with a large contingent of agile preachers) is.<br /><br />And no solving a sudoku puzzle is not "algorithm discovery", any more than writing a for loop is "programming language research".<br /><br /><br />Dismissing writing a sudoku solver as a a problem of "algorithm discovery", is intellectual laziness. It is "discovery" only for people who don't know their trade.Ravihttps://www.blogger.com/profile/03630087669712445498noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-65507736465371024712009-09-21T15:27:21.744-07:002009-09-21T15:27:21.744-07:00A more elaborate reply:
http://vladimirlevin.blog...A more elaborate reply:<br /><br />http://vladimirlevin.blogspot.com/2009/09/spy-vs-spy.htmlNestedhttps://www.blogger.com/profile/09680919094932667147noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-13546132457884574852009-09-21T13:11:50.586-07:002009-09-21T13:11:50.586-07:00I believe the big problem is the ambiguity in the ...I believe the big problem is the ambiguity in the word 'design'. Clearly there are situations where you need to know your over-arching algorithm ahead of time, but that's not always the case. Sometimes you really do have to develop pieces of working code one step at a time and re-evaluate as you go along (whether you write tests as you go is a separate issue). To me 'design' is mostly about the algorithm, i.e. how to solve the problem irrespective of programming language. How do I fill this polygon? How do I encrypt this file? How do I sort this large data set? etc... A separate is step is shaping the code. This is also sometimes referred to as 'design'. This is the step where I think a test-driven approach can be helful in a number of ways: improving the clarity of the code, checking for correctness, and regression.Nestedhttps://www.blogger.com/profile/09680919094932667147noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-63981879285298553372009-09-12T10:29:53.567-07:002009-09-12T10:29:53.567-07:00You had me with the Sandman reference :)
Just kidd...You had me with the Sandman reference :)<br />Just kidding, thanks for the excerpt, I think I will buy this one.chandrakanthttps://www.blogger.com/profile/14510468393909662305noreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-38633248005346240902009-09-12T01:23:50.792-07:002009-09-12T01:23:50.792-07:00"they should only be used as *tests* i.e. to ..."they should only be used as *tests* i.e. to check if something is right/wrong. "<br /><br />And by using them as a regression suite, to continue to ensure that things are *still* right (or wrong).<br /><br />Use of tests to "design" is crazy.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8993901435573921786.post-37118851567476105652009-09-11T22:50:04.019-07:002009-09-11T22:50:04.019-07:00The thing about tests is very correct, they should...The thing about tests is very correct, they should only be used as *tests* i.e. to check if something is right/wrong. People have the tendency to always exploit the good things to a level where they lose their original meaning. So, probably some of those people did this evolution of test -> test driven development -> test driven designhimanshuhttps://www.blogger.com/profile/02909790425038294533noreply@blogger.com