3 ms·

> "Pay $1 if you're late to the standup meeting" If you're discipline enough with your time, you shouldn't worry about things like this. Life is not perfect, t

> "Pay $1 if you're late to the standup meeting" If you're discipline enough with your time, you shouldn't worry about things like this. Life is not perfect, there will always be small things that might bother you but not other people. Take it easy, besides, like I said, if you're punctuate, why does it bother you much? maybe it is meant for your co-workers that have time-management issues. > "No code without passing tests" I've worked with smart people with big ego swinging their code like the best thing since slice of bread. I've worked with smart people who think they can solve everything by raw-talent. I've worked with smart people but not careful. In every situation, forcing TDD help to store "order". People out there seems to echo the same story. Now here's the thing, what should I do? should I accept your story and have blind-faith on the new guys? Thinking that they're smart and all that and no unit-test? Should I trust someone that say "I designed my code to be unit-testable, but I have no time to write unit-tests"? How many allegedly "good developers" out there that my company can afford to pay? Market also determines the price and right now the price of junior developers are quite high. And one more thing: I respect your skill for having over 100 projects over a few years of hacking. That's great. There should be more people like you, and less number of failed projects out there. What I'm trying to say is that the statistics (Standish Group) isn't on your side. TDD is a topic that would always caused a disagreement with a group of programmers who have "success stories" without TDD, open source projects where there are no deadline and have millions contributors (well, eventually the bug will be fixed right... eventually... someday).

Silhouette 16y ago
If you're advocating things like TDD or fixed daily meetings, you should perhaps avoid using words like "statistics". They most certainly are not on your side; indeed, there is very little evidence that these trendy Agile-based processes provide any benefit whatsoever.
- hello_moto 16y ago
  I'm not sold completely on TDD. Part of me think that TDD is a necessary evil. Some organizations have the resources to hire many QAs that might help to reduce the number of unit-tests. I'm not saying that is the most cost effective way to go. Also, if the programmers words can be trusted (that their code is unit-testable, instead of highly-coupled, lots of dependency cycle, etc), writing unit-test last would be alright as well.
  - Silhouette 16y ago
    FWIW, I think the most important thing here is not to confuse use of unit tests with the adoption of TDD. The former does not imply the latter: you can write unit tests after you write your code, or even before/during writing code for that matter, without being test-driven in your approach. I have yet to see any credible study that showed a benefit for TDD and controlled for the use of unit testing as part of a more traditional development process. There is some evidence that, at least for some types of project, TDD has been more successful by some metrics than a heavyweight, waterfall process with no unit testing, but there are usually so many uncontrolled variables involved that it's hard to read much of value into any of those results.

Silhouette 16y ago

If you're advocating things like TDD or fixed daily meetings, you should perhaps avoid using words like "statistics". They most certainly are not on your side; indeed, there is very little evidence that these trendy Agile-based processes provide any benefit whatsoever.

hello_moto 16y ago
I'm not sold completely on TDD. Part of me think that TDD is a necessary evil. Some organizations have the resources to hire many QAs that might help to reduce the number of unit-tests. I'm not saying that is the most cost effective way to go. Also, if the programmers words can be trusted (that their code is unit-testable, instead of highly-coupled, lots of dependency cycle, etc), writing unit-test last would be alright as well.
- Silhouette 16y ago
  FWIW, I think the most important thing here is not to confuse use of unit tests with the adoption of TDD. The former does not imply the latter: you can write unit tests after you write your code, or even before/during writing code for that matter, without being test-driven in your approach. I have yet to see any credible study that showed a benefit for TDD and controlled for the use of unit testing as part of a more traditional development process. There is some evidence that, at least for some types of project, TDD has been more successful by some metrics than a heavyweight, waterfall process with no unit testing, but there are usually so many uncontrolled variables involved that it's hard to read much of value into any of those results.