35 ms·

> But TDD works, you're the sinner for not using it right! I often tell my colleagues that if technologies or methodologies are widely misunderstood, then pra

> But TDD works, you're the sinner for not using it right! I often tell my colleagues that if technologies or methodologies are widely misunderstood, then practitioners aren’t to blame. TDD might be great, but I have yet to see it widely succeed because its adoption is troublesome. It’s a bit like any of these newest products that promise to address everything consumers demand, only to fail miserably against the same old, leaving the few adopters asking themselves why commoners didn’t get it.

gpderetta 5y ago
I believe that in medicine, if a treatment fail because the patient doesn't follow it correctly, it is considered a failure of the treatment (of course better education can be part of the solution).
pydry 5y ago
There are a number of tech fads that were unknowingly widely promoted as a panacea whose applicability is limited to particular specific circumstances. Microservices is another. TDD gets pushed especially hard (I think) because when it works well it works REALLY well and because it can be quite literally addictive - the red/green being like sounds on a slot machine that generate a hit of dopamine. Thats a recipe for some passionate promotion. In fairness to the original author, his heterodox form of TDD does widen its applicability beyond its traditional scope of complex, stateless algorithmic code with simple APIs to the more common integration code that involves databases, etc. that predominates in most commercial code bases.
- parasubvert 5y ago
  But, what tech innovation DIDN’T start as something with limited applicability? The only way to know is to discuss the benefits and tradeoffs in something approaching social science. But humans struggle with rigor, it’s much easier to brand and market something, or to buy in to brands. So “ideas” like microservices become brands. And they’re misunderstood and misapplied because people don’t read the copious literature that discusses the tradeoffs and variations. And they don’t practice it as a discipline with someone that has mastered the technique successfully: they do it blind. Same goes for TDD or other XP practices that are often deride as cultish. being a discipline is even harder to adopt than a design philosophy like microservices. Disciplines are about consistent behaviour. To an outsider, it’s freaky. But calling it cultish as some do is like saying Karate or another martial art is a cult. From the outside it kind of looks like it, but discipline or kata (practice of form) is known to be a success multiplier for the sustained successful application of practices. If you don’t have a dojo or a sensei, could you teach yourself such a set of martial arts to mastery? If not, why do we expect everyone to pick up TDD after reading a book?
- hguant 5y ago
  TDD gets pushed because it creates great, easily trackable metrics one can gesture to as evidence that a) your code is good and b) that you're doing a good job and should be paid more. It makes developers happy because it translates the somewhat arcane nature of the work into something easily digestible by management, and is a fig leaf for shoddy work. It makes management happy because it goes nicely on a chart that can be shown to the director/customer/shareholders, and looks good at status meetings. It also gives them something to poke at and micromanage. It makes the customer/shareholders happy because it provides a metric that their money is being spent _doing something_. TDD may have started as a coding best practice, but it exists and endures - and will continue to exist and endure - because it's performative, and the performance has value to every layer of a business, even though it has nothing to do with actually making the product better at this point.
parasubvert 5y ago
I would agree… except that MOST programming technologies and processes are widely misunderstood, and it feels increasingly so. Get 10 random senior programmers in a room, and see if they agree on matters of design, code structure, testing, frameworks, system architecture. I’ve been part of summits trying to do this several times over the decades, and the only agreement we wound up with was that “Layered abstractions are sometimes a good idea”. There is a lot of duplication of effort in languages, frameworks, and tools driven by “I can’t be bothered to learn this new idea, I know better”, and a lot of misunderstanding of even first principles. Something like TDD (and other XP practices like pairing) reminds me of diet/fitness /nutrition regimens that are notoriously difficult to comply with. This isn’t to say they don’t work: athletes and bodybuilders do exist, as do many successful TDD practitioners. It’s just human nature to avoid things that require mental change, or to be prone to self deception in their application.
- 411111111111111 5y ago
  Another reason why it's so hard to actually say "tdd does/doesn't work" is that everyone has their own idea what it is. Its like everything in software engineering: everyone has an opinion, few have actually tested theirs with performant and stable production deployments
  - falcolas 5y ago
    Or TMTOWTDI. Or there's hidden assumptions that differentiate between a Google solution and a coffee shop solution. Performant... stable... both have ridiculously variable definitions based on who you talk to. That alone is probably enough to get your 10 Sr. developers to provide different solutions.
    - parasubvert 5y ago
      I don’t think the assumptions are hidden. There is plenty of literature with a reasonable discussion of the range of definitions of performance and scale. It’s that people aren’t even looking for them. It’s about “Team Red vs Team Blue”. Or whatever buzzword needs to be on your resume alongside leetcode for the next interview. NoSQL vs SQL, FP vs OOP. Can’t get my raise if I’m building coffee shop solutions! The counter to TMTOWTDI is a set of principles and discipline, at least within a team or a project. Not to outright reject the alternatives, but to recognize the power of consistent behaviour and prioritization of tradeoffs, to try to counter the brand allegiances.
constantine42 5y ago
It's like everything in programming. The 1% of the elite can use almost any methodology with great success, but the other 99% constantly fail to perform. The problem solving aspect of programming is hard for most people. Nearly all of the high performers that I know are on the high functioning autism spectrum. They spearhead the hard technical problems, and set the stage for everyone else to tag along wit the busy work. It takes all kinds to make a team, but we still need to recognize everyone's strengths and weaknesses. And not every problem in programming is a technical problem. There are more issues in communication and understanding the problem being solved. Doesn't do much good to have a technically correct product that doesn't quite solve the problem. What software engineering needs is a methodology in management to identify and properly utilize everyone to their unique abilities.
- neves 5y ago
  Like everything in programming, the cultural part is more difficult than the technical part. I've seen more than one a fellow coworker comment all my tests. If you don't create the correct culture, and there isn't management buy in, it won't work.
randomdata 5y ago
Where are the lines drawn? Take Agile. It clearly outlines that you cannot have managers getting in the way. Yet, I don't know how many companies I've seen trying "Agile" without giving up their managers. If you're not even willing to move past the first step, indeed it is doomed to failure. But surely you should recognize that when you decide to go down that road? Removing the managers from the equation requires a team of developers who have a very business-oriented mindset. I expect a lot of developers don't have that, and may not even be capable of it. For any given business, chances are that does not describe your team. I think it is fair to say that Agile is not realistic in the vast majority of cases. Is the fault Agile for being written for a narrow scope of situations or for practitioners trying to adopt it where it was not designed to fit? I would suggest the latter.
- manuelabeledo 5y ago
  > Is the fault Agile for being written for a narrow scope of situations or for practitioners trying to adopt it where it was not designed to fit? I would suggest the latter. I believe Agile is one of the main offenders here. You suggest that Agile is not "realistic" in most cases, and I agree with that, but Agile consultants and practitioners like to say that Agile is about taking what works for you, and adapting it to your needs. I think Agile adoption by people who believe in this, is doomed. When Agile is seen as a set of nebulous guidelines from where you can pick and choose, it just doesn't work, and in turn, these experiences feed the idea that Agile doesn't work as a whole.
- tored 5y ago
  Agile with managers - We have rearranged your sprints because of super duper important deadline for a very important customer. - But we already begun this sprint! - Yeah, but we are Agile.
ragnese 5y ago
How many of the people who misunderstand the technology or methodology actually learned it from some kind of official or primary source, though? Compare that to how many of us learned "OOP" or "TDD" or "FP" or "DDD" from a few blog posts. Is it physicists' fault that I can "learn" that quantum mechanics says CERN opened up a wormhole and alternate timelines from a crystal salesperson on Facebook?
hinkley 5y ago
I worked with a guy who has since transitioned to teaching Agile methodologies, and one day he was talking about his mentor, 'Jay' and the methodology they used within Jay's consulting practice. Most of the successful projects, Jay brought in a team of people he had worked with before. So at some point you have to ask if it's the methodology that makes the project successful, or the people who make the methodology work. If you have ever been a Lead, or even a viable candidate for one, you've had meetings with others to conspire to be successful within the bounds of whatever rules management won't budge on. How to make this number say what we want it to say. How to make that graph go in the right direction. In these cases we are camouflaging our personal methodologies to pass for someone else's. We are succeeding in spite of them, because if we told them what we were doing they might make us stop. So when they look back at the project, all they see is the things we let them see. The opinion of the person who introduced a change is never the one you can trust. You should ask the people in the trenches what they think.

gpderetta 5y ago

I believe that in medicine, if a treatment fail because the patient doesn't follow it correctly, it is considered a failure of the treatment (of course better education can be part of the solution).

pydry 5y ago

There are a number of tech fads that were unknowingly widely promoted as a panacea whose applicability is limited to particular specific circumstances. Microservices is another. TDD gets pushed especially hard (I think) because when it works well it works REALLY well and because it can be quite literally addictive - the red/green being like sounds on a slot machine that generate a hit of dopamine. Thats a recipe for some passionate promotion. In fairness to the original author, his heterodox form of TDD does widen its applicability beyond its traditional scope of complex, stateless algorithmic code with simple APIs to the more common integration code that involves databases, etc. that predominates in most commercial code bases.

parasubvert 5y ago
But, what tech innovation DIDN’T start as something with limited applicability? The only way to know is to discuss the benefits and tradeoffs in something approaching social science. But humans struggle with rigor, it’s much easier to brand and market something, or to buy in to brands. So “ideas” like microservices become brands. And they’re misunderstood and misapplied because people don’t read the copious literature that discusses the tradeoffs and variations. And they don’t practice it as a discipline with someone that has mastered the technique successfully: they do it blind. Same goes for TDD or other XP practices that are often deride as cultish. being a discipline is even harder to adopt than a design philosophy like microservices. Disciplines are about consistent behaviour. To an outsider, it’s freaky. But calling it cultish as some do is like saying Karate or another martial art is a cult. From the outside it kind of looks like it, but discipline or kata (practice of form) is known to be a success multiplier for the sustained successful application of practices. If you don’t have a dojo or a sensei, could you teach yourself such a set of martial arts to mastery? If not, why do we expect everyone to pick up TDD after reading a book?
hguant 5y ago
TDD gets pushed because it creates great, easily trackable metrics one can gesture to as evidence that a) your code is good and b) that you're doing a good job and should be paid more. It makes developers happy because it translates the somewhat arcane nature of the work into something easily digestible by management, and is a fig leaf for shoddy work. It makes management happy because it goes nicely on a chart that can be shown to the director/customer/shareholders, and looks good at status meetings. It also gives them something to poke at and micromanage. It makes the customer/shareholders happy because it provides a metric that their money is being spent _doing something_. TDD may have started as a coding best practice, but it exists and endures - and will continue to exist and endure - because it's performative, and the performance has value to every layer of a business, even though it has nothing to do with actually making the product better at this point.

parasubvert 5y ago

I would agree… except that MOST programming technologies and processes are widely misunderstood, and it feels increasingly so. Get 10 random senior programmers in a room, and see if they agree on matters of design, code structure, testing, frameworks, system architecture. I’ve been part of summits trying to do this several times over the decades, and the only agreement we wound up with was that “Layered abstractions are sometimes a good idea”. There is a lot of duplication of effort in languages, frameworks, and tools driven by “I can’t be bothered to learn this new idea, I know better”, and a lot of misunderstanding of even first principles. Something like TDD (and other XP practices like pairing) reminds me of diet/fitness /nutrition regimens that are notoriously difficult to comply with. This isn’t to say they don’t work: athletes and bodybuilders do exist, as do many successful TDD practitioners. It’s just human nature to avoid things that require mental change, or to be prone to self deception in their application.

411111111111111 5y ago
Another reason why it's so hard to actually say "tdd does/doesn't work" is that everyone has their own idea what it is. Its like everything in software engineering: everyone has an opinion, few have actually tested theirs with performant and stable production deployments
- falcolas 5y ago
  Or TMTOWTDI. Or there's hidden assumptions that differentiate between a Google solution and a coffee shop solution. Performant... stable... both have ridiculously variable definitions based on who you talk to. That alone is probably enough to get your 10 Sr. developers to provide different solutions.
  - parasubvert 5y ago
    I don’t think the assumptions are hidden. There is plenty of literature with a reasonable discussion of the range of definitions of performance and scale. It’s that people aren’t even looking for them. It’s about “Team Red vs Team Blue”. Or whatever buzzword needs to be on your resume alongside leetcode for the next interview. NoSQL vs SQL, FP vs OOP. Can’t get my raise if I’m building coffee shop solutions! The counter to TMTOWTDI is a set of principles and discipline, at least within a team or a project. Not to outright reject the alternatives, but to recognize the power of consistent behaviour and prioritization of tradeoffs, to try to counter the brand allegiances.

constantine42 5y ago

It's like everything in programming. The 1% of the elite can use almost any methodology with great success, but the other 99% constantly fail to perform. The problem solving aspect of programming is hard for most people. Nearly all of the high performers that I know are on the high functioning autism spectrum. They spearhead the hard technical problems, and set the stage for everyone else to tag along wit the busy work. It takes all kinds to make a team, but we still need to recognize everyone's strengths and weaknesses. And not every problem in programming is a technical problem. There are more issues in communication and understanding the problem being solved. Doesn't do much good to have a technically correct product that doesn't quite solve the problem. What software engineering needs is a methodology in management to identify and properly utilize everyone to their unique abilities.

neves 5y ago
Like everything in programming, the cultural part is more difficult than the technical part. I've seen more than one a fellow coworker comment all my tests. If you don't create the correct culture, and there isn't management buy in, it won't work.

randomdata 5y ago

Where are the lines drawn? Take Agile. It clearly outlines that you cannot have managers getting in the way. Yet, I don't know how many companies I've seen trying "Agile" without giving up their managers. If you're not even willing to move past the first step, indeed it is doomed to failure. But surely you should recognize that when you decide to go down that road? Removing the managers from the equation requires a team of developers who have a very business-oriented mindset. I expect a lot of developers don't have that, and may not even be capable of it. For any given business, chances are that does not describe your team. I think it is fair to say that Agile is not realistic in the vast majority of cases. Is the fault Agile for being written for a narrow scope of situations or for practitioners trying to adopt it where it was not designed to fit? I would suggest the latter.

manuelabeledo 5y ago
> Is the fault Agile for being written for a narrow scope of situations or for practitioners trying to adopt it where it was not designed to fit? I would suggest the latter. I believe Agile is one of the main offenders here. You suggest that Agile is not "realistic" in most cases, and I agree with that, but Agile consultants and practitioners like to say that Agile is about taking what works for you, and adapting it to your needs. I think Agile adoption by people who believe in this, is doomed. When Agile is seen as a set of nebulous guidelines from where you can pick and choose, it just doesn't work, and in turn, these experiences feed the idea that Agile doesn't work as a whole.
tored 5y ago
Agile with managers - We have rearranged your sprints because of super duper important deadline for a very important customer. - But we already begun this sprint! - Yeah, but we are Agile.

ragnese 5y ago

How many of the people who misunderstand the technology or methodology actually learned it from some kind of official or primary source, though? Compare that to how many of us learned "OOP" or "TDD" or "FP" or "DDD" from a few blog posts. Is it physicists' fault that I can "learn" that quantum mechanics says CERN opened up a wormhole and alternate timelines from a crystal salesperson on Facebook?

hinkley 5y ago

I worked with a guy who has since transitioned to teaching Agile methodologies, and one day he was talking about his mentor, 'Jay' and the methodology they used within Jay's consulting practice. Most of the successful projects, Jay brought in a team of people he had worked with before. So at some point you have to ask if it's the methodology that makes the project successful, or the people who make the methodology work. If you have ever been a Lead, or even a viable candidate for one, you've had meetings with others to conspire to be successful within the bounds of whatever rules management won't budge on. How to make this number say what we want it to say. How to make that graph go in the right direction. In these cases we are camouflaging our personal methodologies to pass for someone else's. We are succeeding in spite of them, because if we told them what we were doing they might make us stop. So when they look back at the project, all they see is the things we let them see. The opinion of the person who introduced a change is never the one you can trust. You should ask the people in the trenches what they think.