11–20 of 20 posts
Earlier quoted context omitted.
What is TTD? Or do you mean TDD (Test Driven Development http://en.wikipedia.org/wiki/Test_Driven_Development )?
Now if there was only test driven spelling, I wouldn't keep embarrassing myself on the inter tubes.
Earlier quoted context omitted.
But how could, lets say, demanding TDD ever cost you talented programmers? It won't, ever. This is wrong. TDD may or may not be useful. I'll give it the benefit of the doubt, but in my experience it has been used in a "cargo cult" approach to programming. The last startup I spent significant time at was eventually destroyed because they hired an "Agile/VP" of engineering. He then hired a bunch of guys who could do "T…
But that's not because of TDD, it because of people who couldn't write software. Imagine if those people were also bad at math, would you say math is only occasionally useful? Obviously I agree about "cargo cult" programming, the worst of it is when someone has a religious affinity for pair programming, but thinks testing is a waste of time.
Some day, better tools than the type systems in OCaml and Haskell and TDD will be invented. Let's not get so hung up on either as a solution that we miss out on even better ones (or fail to invent them).
Earlier quoted context omitted.
But that's not because of TDD, it because of people who couldn't write software. Imagine if those people were also bad at math, would you say math is only occasionally useful? Obviously I agree about "cargo cult" programming, the worst of it is when someone has a religious affinity for pair programming, but thinks testing is a waste of time.
I think I am a good programmer, and I think TDD is aweful. Using unit testing, has its place, especially when working with parts that have clear input/output ranges, or in large systems, where your piece of code has to be integrated somewhere else, so you want to make sure it works before committing it. BUT, programming according to Tests, is not a good idea. Tests are not the END RESULT, not the ultimate user of you…
TDD certainly is a good way to help beginners gain confidence and improve their skills. And, I don't see what's so bad about a stronger programmer who chooses to start with the sparse essence of a program rather than building dense stand-alone code at the beginning. Especially if you're already committed to having tests for qc purposes or as a sort of compromised form of literate programming.
Earlier quoted context omitted.
I think I am a good programmer, and I think TDD is aweful. Using unit testing, has its place, especially when working with parts that have clear input/output ranges, or in large systems, where your piece of code has to be integrated somewhere else, so you want to make sure it works before committing it. BUT, programming according to Tests, is not a good idea. Tests are not the END RESULT, not the ultimate user of you…
Working on large and complex application becomes near impossible without extensive unit test coverage. If you're using unit test of all things to guide the design of your application, you are off the deep end. That makes you a bad programmer, it doesn't make TDD bad.
I, for one, would not argue with unit testing (particularly for libraries) or regression testing, but I think that an insistence on TDD can be excessive.
Earlier quoted context omitted.
Working on large and complex application becomes near impossible without extensive unit test coverage. If you're using unit test of all things to guide the design of your application, you are off the deep end. That makes you a bad programmer, it doesn't make TDD bad.
Part of the problem in discussions like these is that people aren't really clear whether they're complaining about testing or TDD in particular, whether they're arguing about the benefits of TDD specifically, unit testing, or testing in general, and everybody involved may read the wrong thing into any ambiguity. I, for one, would not argue with unit testing (particularly for libraries) or regression testing, but I th…
I definitely ascribe to TDBF (Test-Driven Bug Fixing) more than TDD - if a bug shows up in my production code, adding a test to the suite to make sure that bug never comes back gives me a great deal of peace of mind. And it helps if I have enough of a testing framework from initial development (such as data and mock object setup) to add new tests quickly. But I definitely don't do enough testing for it to qualify as TDD.
2) Be “true believers” in Agile methods, including story carding, pair-programming and test-driven development. I am a true believer in TTD, continuous integration and weekly team based code reviews, but pair-programming is crap. Plus, A LOT of very good developers who also love TDD and a lot of Agile/XP practices feel the same way about forced pair programming. Demanding it is a good way to lose a lot of great talen…
I have found it very useful for spreading knowledge amongst a team and for ensuring a tricky or fundamental piece of code.
Earlier quoted context omitted.
Part of the problem in discussions like these is that people aren't really clear whether they're complaining about testing or TDD in particular, whether they're arguing about the benefits of TDD specifically, unit testing, or testing in general, and everybody involved may read the wrong thing into any ambiguity. I, for one, would not argue with unit testing (particularly for libraries) or regression testing, but I th…
That's a good point, I often catch myself conflating TDD with general unit testing. I definitely ascribe to TDBF (Test-Driven Bug Fixing) more than TDD - if a bug shows up in my production code, adding a test to the suite to make sure that bug never comes back gives me a great deal of peace of mind. And it helps if I have enough of a testing framework from initial development (such as data and mock object setup) to a…
As is often the case, most arguments are about extreme positions.
2) Be “true believers” in Agile methods, including story carding, pair-programming and test-driven development. I am a true believer in TTD, continuous integration and weekly team based code reviews, but pair-programming is crap. Plus, A LOT of very good developers who also love TDD and a lot of Agile/XP practices feel the same way about forced pair programming. Demanding it is a good way to lose a lot of great talen…
Why do you believe pair-programming is crap? I have found it very useful for spreading knowledge amongst a team and for ensuring a tricky or fundamental piece of code.
2) Be “true believers” in Agile methods, including story carding, pair-programming and test-driven development. I am a true believer in TTD, continuous integration and weekly team based code reviews, but pair-programming is crap. Plus, A LOT of very good developers who also love TDD and a lot of Agile/XP practices feel the same way about forced pair programming. Demanding it is a good way to lose a lot of great talen…
And I know one fellow--who lives in Canada--who might not care to relocate his family to Jacksonville. He could easily write what you just wrote, this time about the fact that the offices are in Jacksonville.
All of these things--pair programming, Ruby, Jacksonville--are going to cut down the number of talented programmers who want to work for Hashrocket.
Given some set of working conditions, I believe the OP does a good job of explaining why the advertisement does an excellent job of attracting the kind of people who would be interested in working for Hashrocket.
The people who don't like pair programming, ruby, or Jacksonville are not the "market" for the ad.
Hire developers who are passionate about programming.