3 ms·

I'm not sure how well TDD works in the large, but for one man on small projects it's great. It's not substituting for design or anything. It's keeping me from g

I'm not sure how well TDD works in the large, but for one man on small projects it's great. It's not substituting for design or anything. It's keeping me from getting stuck in a rut. But it's possible it's not so much TDD as just the process of managing stories. If that helps understand where I'm coming from.

DanielBMarkham 18y ago
From what I can see (and I've read up a bit and worked with some of the big guys in the field) TDD is a "small shop" kind of philosophy. I would think it would work best in teams of 1-4 developers. 4 or over, however, and it seems like it would fall apart. People factor out code in different ways -- for instance, some naturally lean towards functional code while others lean toward imperative code. In modern languages, you can use both. Some folks love interfaces while others won't stand for a public variable. How code "smells" (and I hate that term) looks to me like it can vary a whole lot depending on the programmer. So in larger teams, you can't have 10 different versions of code re-factoring. You have to expect some consistency. There is a place for group decisions. Some team-level thinking ahead makes sense. But on a 1 or 2 person team? That looks like a completely different animal. What we're finding, however (as consultants), is that companies are getting sold on lightweight technologies that work great at the small team level and then don't work so hot with fifty thousand developers. It's complex. Thanks for the feedback. HappyTDDCoderCount++
- akkartik 18y ago
  Are these fifty thousand developers on a new codebase? Bolting TDD onto legacy software (http://akkartik.name/blog/4664263 http://akkartik.name/blog/4664263) is hard, but that's perhaps different from saying TDD doesn't 'scale'.
  - DanielBMarkham 18y ago
    I must be misunderstanding something. I was expressing concern that it can scale due to the size of the development team. New or old codebases have little to do with. I'm fully aware that TDD works with legacy code. I'm in a learning mode, however. I'm trying to gather all of the data possible. And by data, I mean real, live, large teams who not only use TDD but do so gladly and would never go back to the old ways. Not consultants, authors, teachers, methodologists, coaches, or anybody else who isn't developing code. We've got enough of that already in the biz. In my small world I haven't come across those teams yet. I think several examples along those lines would do the most to show me that TDD was worth picking up both as a personal and as a coaching practice. Having said that, in some ways we may be parsing words. I design in a lightweight fashion top-down and then code and refactor bottom-up, unit testing as I go. In some ways, this IS TDD, except that I'm not using the test-first mantra as a design crutch. I already know how to design.
    - akkartik 18y ago
      I didn't mean to sound critical. I don't really have any experience with large teams. Let me try to rephrase. A large team would probably imply a large codebase, so are you aware of attempts to separate those two variables? For example it's interesting to me that attempts to do TDD on large codebases have met with success. Your response also raised another interesting question. TDD could be hard to scale with team size because of intrinsic issues or just the difficulty in 'infecting' a large group with it. I wonder which is larger part of the reason.

DanielBMarkham 18y ago

From what I can see (and I've read up a bit and worked with some of the big guys in the field) TDD is a "small shop" kind of philosophy. I would think it would work best in teams of 1-4 developers. 4 or over, however, and it seems like it would fall apart. People factor out code in different ways -- for instance, some naturally lean towards functional code while others lean toward imperative code. In modern languages, you can use both. Some folks love interfaces while others won't stand for a public variable. How code "smells" (and I hate that term) looks to me like it can vary a whole lot depending on the programmer. So in larger teams, you can't have 10 different versions of code re-factoring. You have to expect some consistency. There is a place for group decisions. Some team-level thinking ahead makes sense. But on a 1 or 2 person team? That looks like a completely different animal. What we're finding, however (as consultants), is that companies are getting sold on lightweight technologies that work great at the small team level and then don't work so hot with fifty thousand developers. It's complex. Thanks for the feedback. HappyTDDCoderCount++

akkartik 18y ago
Are these fifty thousand developers on a new codebase? Bolting TDD onto legacy software (http://akkartik.name/blog/4664263 http://akkartik.name/blog/4664263) is hard, but that's perhaps different from saying TDD doesn't 'scale'.
- DanielBMarkham 18y ago
  I must be misunderstanding something. I was expressing concern that it can scale due to the size of the development team. New or old codebases have little to do with. I'm fully aware that TDD works with legacy code. I'm in a learning mode, however. I'm trying to gather all of the data possible. And by data, I mean real, live, large teams who not only use TDD but do so gladly and would never go back to the old ways. Not consultants, authors, teachers, methodologists, coaches, or anybody else who isn't developing code. We've got enough of that already in the biz. In my small world I haven't come across those teams yet. I think several examples along those lines would do the most to show me that TDD was worth picking up both as a personal and as a coaching practice. Having said that, in some ways we may be parsing words. I design in a lightweight fashion top-down and then code and refactor bottom-up, unit testing as I go. In some ways, this IS TDD, except that I'm not using the test-first mantra as a design crutch. I already know how to design.
  - akkartik 18y ago
    I didn't mean to sound critical. I don't really have any experience with large teams. Let me try to rephrase. A large team would probably imply a large codebase, so are you aware of attempts to separate those two variables? For example it's interesting to me that attempts to do TDD on large codebases have met with success. Your response also raised another interesting question. TDD could be hard to scale with team size because of intrinsic issues or just the difficulty in 'infecting' a large group with it. I wonder which is larger part of the reason.