3 ms·

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

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

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.