Comments on: The Dangers of Git ‘R Done http://www.codesqueeze.com/the-dangers-of-git-r-done/ Ideas for building efficient developers and software Mon, 30 Jan 2012 11:03:44 -0500 hourly 1 By: Paul Nash http://www.codesqueeze.com/the-dangers-of-git-r-done/#comment-555 Paul Nash Wed, 14 Nov 2007 16:45:17 +0000 http://www.codesqueeze.com/the-dangers-of-git-r-done/#comment-555 error on the side of quality ... indeed! A very good principal. Seriously, I noticed a few spelling errors on these pages, e.g. complaint for compliant. error on the side of quality … indeed!
A very good principal.
Seriously, I noticed a few spelling errors on these pages, e.g. complaint for compliant.

]]> By: Max Pool http://www.codesqueeze.com/the-dangers-of-git-r-done/#comment-18 Max Pool Fri, 29 Jun 2007 15:31:54 +0000 http://www.codesqueeze.com/the-dangers-of-git-r-done/#comment-18 I do not know the exact wording but I do know that we walked away with the generalization that customers were more satisfied with quality over quantity. Your comment of 3 features tested 3 times, or 5 features tested once is a great segue into an example... A few times a single customer wanted two different systems built concurrently. One team did TDD, and the other team did all unit testing after feature complete. By the end of the two budgets which solution did the customer like the best? The TDD team only delivered 85% of initial features but was rock solid. The non-TDD team was 110% feature complete (as the customer kept adding new features) and had 0 tests built and was buggy. As a result, they had to run over budget to create tests and fix bugs. So which is better? It is all in the eye of the client I guess... I do not know the exact wording but I do know that we walked away with the generalization that customers were more satisfied with quality over quantity. Your comment of 3 features tested 3 times, or 5 features tested once is a great segue into an example…

A few times a single customer wanted two different systems built concurrently. One team did TDD, and the other team did all unit testing after feature complete. By the end of the two budgets which solution did the customer like the best?

The TDD team only delivered 85% of initial features but was rock solid.

The non-TDD team was 110% feature complete (as the customer kept adding new features) and had 0 tests built and was buggy. As a result, they had to run over budget to create tests and fix bugs.

So which is better? It is all in the eye of the client I guess…

]]> By: Jason http://www.codesqueeze.com/the-dangers-of-git-r-done/#comment-17 Jason Fri, 29 Jun 2007 14:25:16 +0000 http://www.codesqueeze.com/the-dangers-of-git-r-done/#comment-17 This is good stuff. I see this kind of compromise pop up everywhere. It would be interesting, however, to know the exact wording on that survey. The text "3 working features than 5 semi-working features" seems, to me, to introduce an immediate bias in the response. Something a bit more scientific, although probably still biased, would be: Would you rather have 3 features tested 3 times, or 5 features tested once. This is good stuff. I see this kind of compromise pop up everywhere. It would be interesting, however, to know the exact wording on that survey. The text “3 working features than 5 semi-working features” seems, to me, to introduce an immediate bias in the response. Something a bit more scientific, although probably still biased, would be:

Would you rather have 3 features tested 3 times, or 5 features tested once.

]]>