Hacker News Reader

You can't really think that the fact that some people like TDD and some people hate it is evidence that we're not doing it right?

I think it's evidence that we don't understand it. Compare this to medicine. I think we're Witch Doctors. I don't think that the problem here is sorting out when to use leeches and when to submerge the patient in water,.

I think we need to understand actual physiology and medicine. That leads to understanding blood clotting and the role of bacteria. Which may lead us back to leeches in some cases, and may get us to wash our hands and wash the patients. But it will also lead us to entirely new ways of treating patients and the wholesale rejection of many of the old ways.

So I agree that neither TDD nor Pair Programming are OneTrueMethodologies.

I fully agree that we don't really understand why TDD or Pair work (when they do work) or don't work (when they don't).

Solving that is important in its own right though, not because people do or do not like them.

I don't like doing push-ups, even though I understand at a basic level how they improve my upper body strength. I'm pretty sure that even if we should someday understand why TDD works (or doesn't) that there will still be good software developers that don't (or do) like it.

I was thinking that people championing and rejecting these practices was more a telltale sign that we don't understand them than anything inherently wrong with disliking things.

So wrt pushups, it's as if millions of people were saying, "pushups don't work" and millions of others were saying, "pushups made me strong."

I think if we solve the problem of understanding why these things sometimes work, we will discover some deeper, more important thing. Maybe pair programming isn't about pairing at all, maybe it's really that we suck so bad at code review, and "soling" pair programming will actually make it obsolete.

I don't know, but as they say, "The best way to predict the future is to invent it."

OK, I see what you're saying. Something to the effect of "they can't all be right", so let's figure out what we're missing?

What you're assuming here is that everyone is doing pushups in the same way. Some of the difference between people liking/disliking certain approaches has to be related to not understanding it and applying it in the same way, surely? I myself couldn't get my head around TDD for ages and then it suddenly clicked and I became a complete convert.

>Solving that is important in its own right though, not because people do or do not like them.

Is it? I tend to think of writing software as something like writing literature. Or composing music, perhaps. I don't see people up in arms saying, "Our understanding of writing is broken because some people like to write structured outlines before they write, whereas others just start free-writing and come back to edit." We don't say, "Our understanding of music composition is broken because some songwriters write the lyrics first but others write the melody first." Why is it so important to understand why different programmers employ different techniques?

I don't think that's quite an apt analogy. The different software development methodologies would be more like different medicine school programs or individual medical students' learning styles, not the end production of the doctors (which would be akin to the shipped software product).

I don't think that programming is where medicine is, so I find it difficult to emotionally buy into the idea that Pair Programming is like a Medical School program.

But I accept that if you think we're further along, you'll make that point.

I'm lucky enough to be healthy enough not to need a lot of direct contact with the medical establishment, but I know many people who have had illnesses that were misdiagnosed repeatedly by many different doctors, and a few people who had problems for which medicine's answer was "sorry, we ain't got shit for you, go die plz".

I wouldn't say software development is "ahead" of medicine, though, the two fields are simply not at all comparable. I have yet to hear an analogy between software and another field (architectural engineering comes up a lot and that one is also pretty stupid) that actually makes any sense.

If you view eating as a nutrient-delivery process, then yes, you are wrong to despise mashed potatoes. On the other hand, if we view eating as a recreational activity, then you should eat whatever you want. On the gripping hand, tastes can be changed fairly easily - if you eat mashed potatoes a couple of dozen times, you'll learn to tolerate them.

So is programming about pleasure? About delivering business value? Are we artists, engineers, factory workers, craftsmen? How much weight do we give to the programmer's preferences, versus practices that seem to produce better results on average?

But those are not the important questions. The problem is that we can't even begin to answer those questions, because we don't know what is effective "on average", or how to measure those results.

> On the gripping hand, tastes can be changed fairly easily - if you eat mashed potatoes a couple of dozen times, you'll learn to tolerate them.

My parents used to be proponents of that idea as well, until they encountered me.

They did at least get a cool story out of it which they relate everything Thanksgiving, about the time 10-year-old me grew a pair and simply tossed the mashed potatoes in the trash instead of sitting at the table for 2 hours.

It's true, with the one caveat that you actually have to want to learn to like it, you can't be forced into it by your parents once you're older than 2 or 3. The social difficulty of not eating potatoes is what set me down that path initially :)

> You can't really think that the fact that some people like TDD and some people hate it is evidence that we're not doing it right?

There is no right. There is only works for us and doesn't work for us, and different people may have better success with different methods.

That is true given what we know today, but it feels like saying the gods bless some farmers and curse others. There may not be a right, but I feel there's more to it than just doing what feels good and seeing what happens.

It's more like programming is still an art, not an established engineering field, and there isn't a right or wrong to art and we haven't gotten to the established engineering point yet. We will eventually.