5 ms·

"Two parties in this argument here have shipped real software in crunch mode. Perhaps others in this argument have not." This is a key point. Agile methodology

"Two parties in this argument here have shipped real software in crunch mode. Perhaps others in this argument have not." This is a key point. Agile methodology vendors who wax loudest about TDD and other "core practices" have never shipped any significant software [1]. None of them ever built a software product or a startup. Neither do they show us any decent body of code written with their superior approach [2] (vs talk interminable about how our code will be better if we adopt their advice and pay them the big consulting $$). After all the book is about Coders At Work, not "Methodology Vendors at Work" (which might be an interesting book, in a very horrific fashion). [1] How many of the creators of the Agile Manifesto have shipped any significant software or built a software company? Most (All?) of them are methodology consultants. [2] Kent beck has JUnit. Robert Martin has Finesse. The rest of the agile gurus don't have anything. I leave it to the readers to decide if JUnit and Finesse are significantly superior, designwise, to other Open Source code bases, written without TDD.

markdennehy 17y ago
What a load of tosh. What is this, the "if it's not on the web, it's not real code" party? Show me an embedded system codebase that any of the duct tape people have put together, systems where failures kill people, and tell me you'd be happy depending on those systems, for your chemotherapy or your ABS brakes or your ATM code or your airliner's fly-by-wire system. Bugs in systems like that will kill people, and we're getting to a state these days where those systems are becoming more and more embedded in day to day life and the risk to Joe Soap is getting higher. How long until a bad UI in a GPS iPhone app turns out to be a contributing factor in a bad car accident? Or until a web-based medical app with a hidden bug screws up a dosing calculation for a patient? This whole duct-tape-it-and-ship-the-sucker mentality has got to stop, before someone gets badly hurt.
- plinkplonk 17y ago
  "Show me an embedded system codebase that any of the duct tape people have put together," StrawMan. replace "duct tape programmers" by "TDD/Agile consultants" What do you get? ;-) "tell me you'd be happy depending on those systems, for your chemotherapy or your ABS brakes or your ATM code or your airliner's fly-by-wire system." More Strawmen. Would you be happier if methodology consultants whose only programming experience in the last 10 years was working on a PayRoll System at Chrysler (which failed btw) used TDD to develop your chemotherapy/fly-by-wire/ABS brakes? ;-)
  - markdennehy 17y ago
    Are you asking if I would be happier if there was testing done on my ABS brakes/chemotherapy/fly-by-wire software than if there wasn't? Seriously? You're suggesting there's an alternative? Or are you saying you base your level of happiness on the experience level of the coders involved rather than their test coverage stats? Because last I checked, experience levels meant very little. The Tacoma Narrows bridge was designed by - at the time - the foremost structural engineers in the world. Their paper on its design was recognised as the single most important paper of its kind in that decade. The bridge still fell, not because they were wrong, but because of something nobody had encountered yet (in this case, aerodynamic flutter). Critical code is precisely that - critical. You don't leave it to the "gifted engineer" model of development because that always fails. Noone is gifted and diligent 100% of the time, everyone screws up eventually. It's dangerously arrogant to think otherwise. You build a system of work that lowers the probability that those screwups make it into a working system, that's all. Civil and Mech. and other engineering branches have been doing it for decades. We're just getting started on it in this branch of engineering.
    - eugenejen 17y ago
      You can not write tests that test/discover defects that you don't know as defects. The Tacoma Bridge case proves exactly the above statement. If we all can conceive tests that remove all defects from past, now and future, then we all live perfect lives. But that is impossible, though we can try to minimize the impact. The problem is probably is undecidable in computational complexity sense. And to some point, we need people, maybe our beloved one, maybe ourselves to be sacrificed in order for scientists and engineers in the next generation to figure out and put them into their test cases to avoid repetition of tragedies. I think you misunderstand gifted engineers. Gifted engineers understand what they shipped are imperfect, but they have guts to ship them and see how they work. The failure will be lessons for next generation to learn. I feel more scared of people who think their tests have removed all known defects while they forget about unknown defects. They have committed the sin of "confirmation bias" and is much worse to welfare of humanity.
      - deleted 17y ago
deleted 17y ago
[deleted]
ZeroGravitas 17y ago
You don't actually say that no real developers use TDD, but you seem to imply that by focusing on the fact that the teachers, authors, consultants and trainers that promote it "loudest" are earning money via the teaching, authoring, consulting and training in which they loudly promote it. Bit of a catch-22 there, no? Since if their job involves communication about programming topics you automatically ignore the message and you'll only listen to those not trying to communicate. Luckily, I just finished reading this article by one of the Twisted guys in relation to the recent release of Tornado which, in passing, sings the praises of TDD, basically calling it essential for the work they do: http://glyph.twistedmatrix.com/2009/09/diesel-case-study-in-that-thing-i-just_24.html http://glyph.twistedmatrix.com/2009/09/diesel-case-study-in-...
- wglb 17y ago
  Check out what the coders (or developers) in Coders at Work say about TDD. It is said much better there than I can.
- plinkplonk 17y ago
  "You don't actually say that no real developers use TDD, but you seem to imply that by focusing on the fact that the teachers, authors, consultants and trainers that promote it "loudest" are earning money via the teaching, authoring, consulting and training in which they loudly promote it." No that isn't what I am saying. I am saying many of these people have no programming experience worth a damn. If someone were to tell me how to program(which is what all these methodology sellers do), they would be much more credible if they actually had the programming chops to back it up. Musashi writing a book on swordsmanship is one thing. If I (who couldn't wield a samurai sword to save his life) write a book that claims my "style" of swordsmanship is better than anything all the others existent today, I shouldn't be surprised if practicing swordsmen don't pay me much heed. It is the juxtaposition of people with no demonstrated/demonstrable programming skills being loud and obnoxious about the superiority of their advice about programming which I pointed to. I was also careful to distinguish between Beck and Martin (who at least walk the walk by putting out code developed using the methods they preach) from the other more "all hat no cattle" folks like Jeffries. so to answer your question, "Bit of a catch-22 there, no? " No, Not at all. :-). I don't have any problems with people telling me how to program. But I don't trust people who demonstrate convincingly that they know nothing about programming (like Ron Jeffries does with his Sudoku code) who also claim to be "masters" of programming. That would be like trying to learn fighting skills from a martial arts "master" you saw getting bashed around by a couple of punks at the bar last night, and ended up being taken to hospital and is still covered with bandages and walks with a limp! A master who wins fights would be much more convincing if he claimed he discovered a new martial art which makes existing ones obsolete. I explicitly said "None of them ever built a software product or a startup. Neither do they show us any decent body of code written with their superior approach (vs talk interminably about how our code will be better if we adopt their advice and pay them the big consulting $$)." I stand by this. These guys write books that are the programming equivalent of "Who Moved My Cheese"?. "Coders at Work" otoh, focusses on people who actually are great programmers. Each interview contains more wisdom on programming than reams of "agile" (and these days "lean") textbooks. FWIW, I did TDD almost exclusively for three years (when I worked at ThoughtWorks), but I don't do TDD anymore, though I still have unit tests.

markdennehy 17y ago

What a load of tosh. What is this, the "if it's not on the web, it's not real code" party? Show me an embedded system codebase that any of the duct tape people have put together, systems where failures kill people, and tell me you'd be happy depending on those systems, for your chemotherapy or your ABS brakes or your ATM code or your airliner's fly-by-wire system. Bugs in systems like that will kill people, and we're getting to a state these days where those systems are becoming more and more embedded in day to day life and the risk to Joe Soap is getting higher. How long until a bad UI in a GPS iPhone app turns out to be a contributing factor in a bad car accident? Or until a web-based medical app with a hidden bug screws up a dosing calculation for a patient? This whole duct-tape-it-and-ship-the-sucker mentality has got to stop, before someone gets badly hurt.

plinkplonk 17y ago
"Show me an embedded system codebase that any of the duct tape people have put together," StrawMan. replace "duct tape programmers" by "TDD/Agile consultants" What do you get? ;-) "tell me you'd be happy depending on those systems, for your chemotherapy or your ABS brakes or your ATM code or your airliner's fly-by-wire system." More Strawmen. Would you be happier if methodology consultants whose only programming experience in the last 10 years was working on a PayRoll System at Chrysler (which failed btw) used TDD to develop your chemotherapy/fly-by-wire/ABS brakes? ;-)
- markdennehy 17y ago
  Are you asking if I would be happier if there was testing done on my ABS brakes/chemotherapy/fly-by-wire software than if there wasn't? Seriously? You're suggesting there's an alternative? Or are you saying you base your level of happiness on the experience level of the coders involved rather than their test coverage stats? Because last I checked, experience levels meant very little. The Tacoma Narrows bridge was designed by - at the time - the foremost structural engineers in the world. Their paper on its design was recognised as the single most important paper of its kind in that decade. The bridge still fell, not because they were wrong, but because of something nobody had encountered yet (in this case, aerodynamic flutter). Critical code is precisely that - critical. You don't leave it to the "gifted engineer" model of development because that always fails. Noone is gifted and diligent 100% of the time, everyone screws up eventually. It's dangerously arrogant to think otherwise. You build a system of work that lowers the probability that those screwups make it into a working system, that's all. Civil and Mech. and other engineering branches have been doing it for decades. We're just getting started on it in this branch of engineering.
  - eugenejen 17y ago
    You can not write tests that test/discover defects that you don't know as defects. The Tacoma Bridge case proves exactly the above statement. If we all can conceive tests that remove all defects from past, now and future, then we all live perfect lives. But that is impossible, though we can try to minimize the impact. The problem is probably is undecidable in computational complexity sense. And to some point, we need people, maybe our beloved one, maybe ourselves to be sacrificed in order for scientists and engineers in the next generation to figure out and put them into their test cases to avoid repetition of tragedies. I think you misunderstand gifted engineers. Gifted engineers understand what they shipped are imperfect, but they have guts to ship them and see how they work. The failure will be lessons for next generation to learn. I feel more scared of people who think their tests have removed all known defects while they forget about unknown defects. They have committed the sin of "confirmation bias" and is much worse to welfare of humanity.
    - deleted 17y ago

deleted 17y ago

[deleted]

ZeroGravitas 17y ago

You don't actually say that no real developers use TDD, but you seem to imply that by focusing on the fact that the teachers, authors, consultants and trainers that promote it "loudest" are earning money via the teaching, authoring, consulting and training in which they loudly promote it. Bit of a catch-22 there, no? Since if their job involves communication about programming topics you automatically ignore the message and you'll only listen to those not trying to communicate. Luckily, I just finished reading this article by one of the Twisted guys in relation to the recent release of Tornado which, in passing, sings the praises of TDD, basically calling it essential for the work they do: http://glyph.twistedmatrix.com/2009/09/diesel-case-study-in-that-thing-i-just_24.html http://glyph.twistedmatrix.com/2009/09/diesel-case-study-in-...

wglb 17y ago
Check out what the coders (or developers) in Coders at Work say about TDD. It is said much better there than I can.
plinkplonk 17y ago
"You don't actually say that no real developers use TDD, but you seem to imply that by focusing on the fact that the teachers, authors, consultants and trainers that promote it "loudest" are earning money via the teaching, authoring, consulting and training in which they loudly promote it." No that isn't what I am saying. I am saying many of these people have no programming experience worth a damn. If someone were to tell me how to program(which is what all these methodology sellers do), they would be much more credible if they actually had the programming chops to back it up. Musashi writing a book on swordsmanship is one thing. If I (who couldn't wield a samurai sword to save his life) write a book that claims my "style" of swordsmanship is better than anything all the others existent today, I shouldn't be surprised if practicing swordsmen don't pay me much heed. It is the juxtaposition of people with no demonstrated/demonstrable programming skills being loud and obnoxious about the superiority of their advice about programming which I pointed to. I was also careful to distinguish between Beck and Martin (who at least walk the walk by putting out code developed using the methods they preach) from the other more "all hat no cattle" folks like Jeffries. so to answer your question, "Bit of a catch-22 there, no? " No, Not at all. :-). I don't have any problems with people telling me how to program. But I don't trust people who demonstrate convincingly that they know nothing about programming (like Ron Jeffries does with his Sudoku code) who also claim to be "masters" of programming. That would be like trying to learn fighting skills from a martial arts "master" you saw getting bashed around by a couple of punks at the bar last night, and ended up being taken to hospital and is still covered with bandages and walks with a limp! A master who wins fights would be much more convincing if he claimed he discovered a new martial art which makes existing ones obsolete. I explicitly said "None of them ever built a software product or a startup. Neither do they show us any decent body of code written with their superior approach (vs talk interminably about how our code will be better if we adopt their advice and pay them the big consulting $$)." I stand by this. These guys write books that are the programming equivalent of "Who Moved My Cheese"?. "Coders at Work" otoh, focusses on people who actually are great programmers. Each interview contains more wisdom on programming than reams of "agile" (and these days "lean") textbooks. FWIW, I did TDD almost exclusively for three years (when I worked at ThoughtWorks), but I don't do TDD anymore, though I still have unit tests.