4 ms·

Yes. I was going to come on here and say the same thing: this guy doesn't know what the heck he is talking about. Your point is an excellent one. If you see hu

Yes. I was going to come on here and say the same thing: this guy doesn't know what the heck he is talking about. Your point is an excellent one. If you see hundreds of really smart people doing X and seemingly very happy with it, there's probably something going on there that's more important than just a bunch of fools with a fad. It might not be appropriate in your situation, it might be oversold by those folks -- but it's highly unlikely that's it's stupid and dumb. I work with training developers all the time. It continues to amaze me how people go from being a novice to being an expert. One day they can't code at all. Next day they know everything there is to know about it -- and can go on at length about why process X is a terrible thing, without even trying or understanding it. Of course, we have the opposite problem in development also. People get sold on ideas that will never work simply because they sound cool or the cool kids are doing them. This reminds me of the old saying "Always be open-minded -- just not empty-headed"

Gigablah 11y ago
> It continues to amaze me how people go from being a novice to being an expert. One day they can't code at all. Next day they know everything there is to know about it -- and can go on at length about why process X is a terrible thing, without even trying or understanding it. The Dunning-Kruger effect in action.
- zimpenfish 11y ago
  > The Dunning-Kruger effect in action. But that also applies to ... >> If you see hundreds of really smart people doing X and seemingly very happy with it, there's probably something going on there
  - Gigablah 11y ago
    That's less Dunning-Kruger and more appeal-to-authority fallacy.
blub 11y ago
Unfortunately when it comes to software development, you can count on many techniques, processes and tools being exactly that: fads packaged expertly by consultants and salesmen to be gobbled up by the masses of managers, architects and developers in exchange for big bucks from trainings, courses and certificates. And you can bet that they will oversell it, hype it and denounce everyone that's trying to be reasonable as old fashioned, conservative and inflexible. Extreme Programming has through its "extremeness" brought automated unit testing front and center. That doesn't mean it's necessarily a good idea to do XP or TDD. Unit tests are now a mainstream idea, and being pedantic and militant about when exactly they should be written and what are the steps needed to be blessed as using the approved way is not being helpful.
- DanielBMarkham 11y ago
  Damn. The misunderstanding just goes on and on. TDD is not a unit testing religion. It's a way of designing software. Some have even advocated calling it Test-Driven Design, not Test-Driven Development, because the end result is a design, not a series of tests. This is important to know, because the key factor in the red-green-blue cycle is the blue step: refactoring. The example given by the author is of a system that kept getting tests -- but was never refactored. Instead, more junk kept got thrown in. In this case, they were not doing the most important thing in TDD, refactoring. Not really sure you can even call this TDD. Looks more like a CF created by a bunch of folks under time pressure who thought it would be easier to add stuff than refactor. If you don't understand what it is, probably not a good idea to criticize it. TDD is a way at looking at constructing OO programs. It's main competitor is probably more along the lines of Model-Driven Development. TDD is a response to the large amount of commercial code being written in complex object-oriented environments. The goal is to ensure that changes to the code maintain the economic value of the code. In my opinion it is not appropriate where there is little or no economic value, like personal, academic, and start-up code. In cases where there are not complex object graphs full of dependencies, such as small pure FP projects, it's also not indicated -- there's no OO system for TDD to help you design. And if you're not designing stuff, you're not doing TDD. People get religious about TDD, yep, and it drives me nuts. But like I said, that's no reason not to understand what the hell is going on before criticizing it. Unfortunately, people getting excited and over-selling things is just the way it is in tech, whether it's TDD or the latest cool programming language.

Gigablah 11y ago

> It continues to amaze me how people go from being a novice to being an expert. One day they can't code at all. Next day they know everything there is to know about it -- and can go on at length about why process X is a terrible thing, without even trying or understanding it. The Dunning-Kruger effect in action.

zimpenfish 11y ago
> The Dunning-Kruger effect in action. But that also applies to ... >> If you see hundreds of really smart people doing X and seemingly very happy with it, there's probably something going on there
- Gigablah 11y ago
  That's less Dunning-Kruger and more appeal-to-authority fallacy.

blub 11y ago

Unfortunately when it comes to software development, you can count on many techniques, processes and tools being exactly that: fads packaged expertly by consultants and salesmen to be gobbled up by the masses of managers, architects and developers in exchange for big bucks from trainings, courses and certificates. And you can bet that they will oversell it, hype it and denounce everyone that's trying to be reasonable as old fashioned, conservative and inflexible. Extreme Programming has through its "extremeness" brought automated unit testing front and center. That doesn't mean it's necessarily a good idea to do XP or TDD. Unit tests are now a mainstream idea, and being pedantic and militant about when exactly they should be written and what are the steps needed to be blessed as using the approved way is not being helpful.

DanielBMarkham 11y ago
Damn. The misunderstanding just goes on and on. TDD is not a unit testing religion. It's a way of designing software. Some have even advocated calling it Test-Driven Design, not Test-Driven Development, because the end result is a design, not a series of tests. This is important to know, because the key factor in the red-green-blue cycle is the blue step: refactoring. The example given by the author is of a system that kept getting tests -- but was never refactored. Instead, more junk kept got thrown in. In this case, they were not doing the most important thing in TDD, refactoring. Not really sure you can even call this TDD. Looks more like a CF created by a bunch of folks under time pressure who thought it would be easier to add stuff than refactor. If you don't understand what it is, probably not a good idea to criticize it. TDD is a way at looking at constructing OO programs. It's main competitor is probably more along the lines of Model-Driven Development. TDD is a response to the large amount of commercial code being written in complex object-oriented environments. The goal is to ensure that changes to the code maintain the economic value of the code. In my opinion it is not appropriate where there is little or no economic value, like personal, academic, and start-up code. In cases where there are not complex object graphs full of dependencies, such as small pure FP projects, it's also not indicated -- there's no OO system for TDD to help you design. And if you're not designing stuff, you're not doing TDD. People get religious about TDD, yep, and it drives me nuts. But like I said, that's no reason not to understand what the hell is going on before criticizing it. Unfortunately, people getting excited and over-selling things is just the way it is in tech, whether it's TDD or the latest cool programming language.