Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

leanprogramming · Lean Programming

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 418
  • Category: Development
  • Founded: Aug 19, 2007
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Messages

Advanced
Messages Help
Messages 764 - 793 of 940   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#764 From: "chrishand40" <cj.hand@...>
Date: Mon Jan 25, 2010 5:44 pm
Subject: ClassFactories vs dependancy injection
chrishand40
Send Email Send Email
 
Can someone explain when would I want to prefer one over the other?

Thanks,
-Chris

#765 From: Scott Bain <slbain@...>
Date: Mon Jan 25, 2010 6:14 pm
Subject: RE: ClassFactories vs dependancy injection
slbain9000
Send Email Send Email
 

It’s an interesting question, Chris.  Thanks for posting it.

 

There are some ways in which this is an either/or question (ways in which DI and factories relate) and some ways in which it is not (where they have different motivations).

 

Some ways they relate… 

1.       They both Separate the use of something from its creation, which I think is a good separation of concerns. 

2.       They both also help encapsulate variation (if the object being injected/constructed varies, as is usually the case).

 

Some ways they are more different… 

1.       Factories help to encapsulate business rules in a single place.  If, for instance, you are building a decorator chain of various behaviors, then a factory can impose rules about what chains can be built and which cannot, or which should be built under what circumstances.  If a client object builds the chain to inject it into a service, and the service has more than one client, then the rules are spread out and often redundant.

2.       DI, on the other hand, can be very useful in breaking dependencies for testing (it is easy to inject a mock directly if the dependency is already “inject-able”, for example).  If you let a factory “decide” to build a mock, then the factory can get coupled to testing issues.

 

Of course, they can be used together as well.  A Client can use a factory to build a dependency, and then inject what the factory built into the Service.  A test could inject  a mock instead, ignoring the factory.  This can be overkill, of course, but if one needs the benefits of both, one can use them in this way.

 

That’s my first bit of thinking, anyway.  Let’s see what others say.

 

-Scott-

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
Sent: Monday, January 25, 2010 9:44 AM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] ClassFactories vs dependancy injection

 

 

Can someone explain when would I want to prefer one over the other?

Thanks,
-Chris


#766 From: Christopher Sage <bigbuffwolf@...>
Date: Mon Jan 25, 2010 6:35 pm
Subject: Re: ClassFactories vs dependancy injection
bigbuffwolf
Send Email Send Email
 
It would also depend upon what your goal is.  Is there anything in particular you're trying to solve, or is this just a general question?

-Chris

On Mon, Jan 25, 2010 at 12:14 PM, Scott Bain <slbain@...> wrote:
 

It’s an interesting question, Chris.  Thanks for posting it.

 

There are some ways in which this is an either/or question (ways in which DI and factories relate) and some ways in which it is not (where they have different motivations).

 

Some ways they relate… 

1.       They both Separate the use of something from its creation, which I think is a good separation of concerns. 

2.       They both also help encapsulate variation (if the object being injected/constructed varies, as is usually the case).

 

Some ways they are more different… 

1.       Factories help to encapsulate business rules in a single place.  If, for instance, you are building a decorator chain of various behaviors, then a factory can impose rules about what chains can be built and which cannot, or which should be built under what circumstances.  If a client object builds the chain to inject it into a service, and the service has more than one client, then the rules are spread out and often redundant.

2.       DI, on the other hand, can be very useful in breaking dependencies for testing (it is easy to inject a mock directly if the dependency is already “inject-able”, for example).  If you let a factory “decide” to build a mock, then the factory can get coupled to testing issues.

 

Of course, they can be used together as well.  A Client can use a factory to build a dependency, and then inject what the factory built into the Service.  A test could inject  a mock instead, ignoring the factory.  This can be overkill, of course, but if one needs the benefits of both, one can use them in this way.

 

That’s my first bit of thinking, anyway.  Let’s see what others say.

 

-Scott-

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
Sent: Monday, January 25, 2010 9:44 AM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] ClassFactories vs dependancy injection

 

 

Can someone explain when would I want to prefer one over the other?

Thanks,
-Chris



#767 From: Allan Schougaard <allanschougaard@...>
Date: Mon Jan 25, 2010 8:24 pm
Subject: Re: ClassFactories vs dependancy injection
allanschougaard
Send Email Send Email
 
Why one or the other?

DI essentially just says (one interpretation) that the agency in charge of
creating objects and tying them together should not be the
(base/domain/business/bean) objects themselves.
Factories can be seen as just accessors and modifiers (getters and setters) on
object in the process of being created.

In fact, just the other day I used a static factory for to create objects for
Spring (java) to inject (because I needed an parameter of type Class<T> which
Spring has a little trouble with).

Thanks,
--Allan

--- On Mon, 1/25/10, chrishand40 <cj.hand@...> wrote:

> From: chrishand40 <cj.hand@...>
> Subject: [leanprogramming] ClassFactories vs dependancy injection
> To: leanprogramming@yahoogroups.com
> Date: Monday, January 25, 2010, 9:44 AM
> Can someone explain when would I want
> to prefer one over the other?
>
> Thanks,
> -Chris

#768 From: "Max Guernsey, III" <max@...>
Date: Tue Jan 26, 2010 2:13 am
Subject: RE: ClassFactories vs dependancy injection
maxguernseyiii
Send Email Send Email
 

I’m fairly certain that Scott summed up the issues nicely.  I’ll admit, I don’t know what the term “ClassFactories” means and could interpret it one of two ways…

 

Way #1:

public class ToBeBuilt {

 private ToBeBuilt() { }

 

 // this is my class factory

 public static ToBeBuilt GetInstance() {

 }

}

 

Way #2:

public class ToBeBuilt {

}

 

// this is my class factory:

public class BuildsObjects {

 public ToBeBuilt MakeRequestedObject() {

 }

}

 

Practically speaking (for myself only), I’m fairly inflexible in this area when it comes to code I am writing.  Thanks to Scott, I always do Way #1.  I do this on principle: Construction is simple too intimate a detail for a class to expose.

 

I vary between Way #2 and dependency injection based on whether or not procurement of a new object is a behavior of the client I am writing and whether or not the client object uses the dependent object.  I do this according to the following rules:

 

When the client…

·         …uses but does not procure: Pass object in at the time when variation should occur

·         …uses and procures: Pass in some kind of provider (a Builder, an Abstract Factory, etc.) when the variation should occur

·         …procures but does not use: Directly invoke the GetInstance() of the right object at the right time

·         …procures and does not use but the above approach would be difficult to test: Reevaluate design; fall back on passing in some kind of provider

·         …doesn’t procure and does not use: Um.  Hmm.  Is this really a dependency or is it just idle coupling?

Note that “use” includes using an object as the input for the creation of another object.

 

Anyway.  I’m not sure if this is directly related to your question or just tangentially related but that’s never stopped me before.

 

-- Max

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott Bain
Sent: Monday, January 25, 2010 10:15 AM
To: leanprogramming@yahoogroups.com
Subject: RE: [leanprogramming] ClassFactories vs dependancy injection

 

 

It’s an interesting question, Chris.  Thanks for posting it.

 

There are some ways in which this is an either/or question (ways in which DI and factories relate) and some ways in which it is not (where they have different motivations).

 

Some ways they relate… 

1.       They both Separate the use of something from its creation, which I think is a good separation of concerns. 

2.       They both also help encapsulate variation (if the object being injected/constructed varies, as is usually the case).

 

Some ways they are more different… 

1.       Factories help to encapsulate business rules in a single place.  If, for instance, you are building a decorator chain of various behaviors, then a factory can impose rules about what chains can be built and which cannot, or which should be built under what circumstances.  If a client object builds the chain to inject it into a service, and the service has more than one client, then the rules are spread out and often redundant.

2.       DI, on the other hand, can be very useful in breaking dependencies for testing (it is easy to inject a mock directly if the dependency is already “inject-able”, for example).  If you let a factory “decide” to build a mock, then the factory can get coupled to testing issues.

 

Of course, they can be used together as well.  A Client can use a factory to build a dependency, and then inject what the factory built into the Service.  A test could inject  a mock instead, ignoring the factory.  This can be overkill, of course, but if one needs the benefits of both, one can use them in this way.

 

That’s my first bit of thinking, anyway.  Let’s see what others say.

 

-Scott-

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
Sent: Monday, January 25, 2010 9:44 AM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] ClassFactories vs dependancy injection

 

 

Can someone explain when would I want to prefer one over the other?

Thanks,
-Chris

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.432 / Virus Database: 271.1.1/2643 - Release Date: 01/25/10 07:36:00


#769 From: "chrishand40" <cj.hand@...>
Date: Mon Feb 1, 2010 8:20 am
Subject: Re: ClassFactories vs dependancy injection
chrishand40
Send Email Send Email
 
It is a general question.

I was reading around on the issue, and there is a strong push to favor DI over
class factories.  The thing that concerned me is the religiousness of it, as if
DI where the higher evolved form of coding.   Two reasons that I thought were
interesting are: 1) class factories violate the open / close principal, and 2)
Heavy use of class factories results in a lot of class factories in your
project.  Given how they are used, I'm not sure I care about #1, and at least in
the size of the projects I am doing, #2 hasn't been an issue.

As I learned more, I realized I didn't really phrase the question well.  While I
have found dependency injection to be very useful when properly applied, my
larger concern is with the large and complex dependency injection frameworks. 
So far I've only worked on one project that used a framework and while I could
see some advantages - it wasn't done very well (IMO).  There was still a lot of
coupling in that if I wanted to change the source of data to be anything other
than a database it would involve a significant effort.  It also added a learning
curve just trying to understand what instances of which object would be created
when.

So far, the answer I have gathered from the group is that it isn't an either/or
answer – they are different tools for different situations.

I'm going to post my question about DI frameworks on a separate thread.


--- In leanprogramming@yahoogroups.com, Christopher Sage <bigbuffwolf@...>
wrote:
>
> It would also depend upon what your goal is.  Is there anything in
> particular you're trying to solve, or is this just a general question?
>
> -Chris
>
> On Mon, Jan 25, 2010 at 12:14 PM, Scott Bain <slbain@...>wrote:
>
> >
> >
> >  It's an interesting question, Chris.  Thanks for posting it.
> >
> >
> >
> > There are some ways in which this is an either/or question (ways in which
> > DI and factories relate) and some ways in which it is not (where they have
> > different motivations).
> >
> >
> >
> > Some ways they relate…
> >
> > 1.       They both Separate the use of something from its creation, which
> > I think is a good separation of concerns.
> >
> > 2.       They both also help encapsulate variation (if the object being
> > injected/constructed varies, as is usually the case).
> >
> >
> >
> > Some ways they are more different…
> >
> > 1.       Factories help to encapsulate business rules in a single place.
> > If, for instance, you are building a decorator chain of various behaviors,
> > then a factory can impose rules about what chains can be built and which
> > cannot, or which should be built under what circumstances.  If a client
> > object builds the chain to inject it into a service, and the service has
> > more than one client, then the rules are spread out and often redundant.
> >
> > 2.       DI, on the other hand, can be very useful in breaking
> > dependencies for testing (it is easy to inject a mock directly if the
> > dependency is already "inject-able", for example).  If you let a factory
> > "decide" to build a mock, then the factory can get coupled to testing
> > issues.
> >
> >
> >
> > Of course, they can be used together as well.  A Client can use a factory
> > to build a dependency, and then inject what the factory built into the
> > Service.  A test could inject  a mock instead, ignoring the factory.  This
> > can be overkill, of course, but if one needs the benefits of both, one can
> > use them in this way.
> >
> >
> >
> > That's my first bit of thinking, anyway.  Let's see what others say.
> >
> >
> >
> > -Scott-
> >
> >
> >
> > *From:* leanprogramming@yahoogroups.com [mailto:
> > leanprogramming@yahoogroups.com] *On Behalf Of *chrishand40
> > *Sent:* Monday, January 25, 2010 9:44 AM
> > *To:* leanprogramming@yahoogroups.com
> > *Subject:* [leanprogramming] ClassFactories vs dependancy injection
> >
> >
> >
> >
> >
> > Can someone explain when would I want to prefer one over the other?
> >
> > Thanks,
> > -Chris
> >
> >
> >
>

#770 From: "chrishand40" <cj.hand@...>
Date: Mon Feb 1, 2010 8:27 am
Subject: Dependency Injection Frameworks
chrishand40
Send Email Send Email
 
What is the take on these?  When would you say "this project would benefit"?

A project would be taking on a respectible sized dependency just adding a DI
framework (for example MS Unity).  Given the size and complexity - I'm wondering
if it is really worth it?

I don't have much experience using them, so maybe there is a big win that I have
yet to see.

#771 From: Christopher Sage <bigbuffwolf@...>
Date: Mon Feb 1, 2010 3:20 pm
Subject: Re: Dependency Injection Frameworks
bigbuffwolf
Send Email Send Email
 
I would say that dependency injection frameworks are a good tool to use when you need/would like something to manage that for you.  In my opinion, any project would benefit for injecting your items for services and data access, for example.

I use Spring with my java projects , which has a lot of different modules that you can use for whatever you're doing.  Each of these individual modules are very small.  There is also a version of Spring for .NET, though I haven't yet tried to use it.  If it's anything like the java version, it'll be first-rate.

As for the complexity, I would say that it reduces the complexity of your DI, especially in regards to your database stuff; it has modules to help you with your data access, using some support classes which help with handling the connection open/closing among other things whether you use hibernate, plain sql, and a couple other ORM technologies.

-Chris


On Mon, Feb 1, 2010 at 2:27 AM, chrishand40 <cj.hand@...> wrote:
 

What is the take on these? When would you say "this project would benefit"?

A project would be taking on a respectible sized dependency just adding a DI framework (for example MS Unity). Given the size and complexity - I'm wondering if it is really worth it?

I don't have much experience using them, so maybe there is a big win that I have yet to see.



#772 From: "gregbanister" <gregbanister@...>
Date: Mon Feb 1, 2010 3:40 pm
Subject: Re: Dependency Injection Frameworks
gregbanister
Send Email Send Email
 
There are many good open source "DI frameworks" / "IOC Containers" (I probably
shouldn't, but I tend to use these two terms interchangeably) .  To name a few
in the .Net space there is Castle Windsor, StructureMap, NinJect, Autofac, and
more that you can see in this post
http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx
At the risk of starting a flame war, I'll say that IMHO Unity is not one of the
"good" ones... "good" being very subjective.  I've been very happy with both
Castle and StructureMap.  NinJect and Autocac seem very popular although I
haven't used them yet, I plan to check them out.

An IOC container helps me accomplish the following:
1) Test-Driven Development
2) Achieving low coupling in my designs
3) Application Configuration
4) Fine grain control over Object lifecycle
5) Decomposition in design (maybe this is the same as #2)
6) Making boundries explicit and intention revieling

Note: This isn't an exahstive list of the benifist in using an IOC container,
it's just what quickly comes to mind.

I'm sure you can do all of this without a DI framework / IOC container, but the
tool will make all of this a lot easier.

In most situations, when you take on a "dependency just by adding a DI
framework", that dependency donsn't have to leak throuought your application. 
For instance, your entire application can be written without the knowledge of
any specific container or DI Framework accept for your the entry point where the
configuration of your dependencies are enacted (i.e. in Program.Main() or
Global.Application_Start()).  In most situations, by simply using constructor
injection, I'm able to keep the dependency on a container completely out of an
application except for the entry point.  If there are situations where you have
to access a container deep within your application to act as a "service broker",
then you can do so by providing your own static abastration over whatever
container you're using.  This (rare for me) situation makes for more friction
durring TDD, but it's realativly painless.

I think 95% percent of the applications I write utilize a DI Framework / IOC
Container unless it's a very simple utility application that consists of a very
small amouont of classes (i.e. less than five) that I did not design using TDD.

Greg

--- In leanprogramming@yahoogroups.com, "chrishand40" <cj.hand@...> wrote:
>
> What is the take on these?  When would you say "this project would benefit"?
>
> A project would be taking on a respectible sized dependency just adding a DI
framework (for example MS Unity).  Given the size and complexity - I'm wondering
if it is really worth it?
>
> I don't have much experience using them, so maybe there is a big win that I
have yet to see.
>

#773 From: "Max Guernsey, III" <max@...>
Date: Mon Feb 1, 2010 3:46 pm
Subject: RE: Dependency Injection Frameworks
maxguernseyiii
Send Email Send Email
 

Myself, I don’t use “dependency injection frameworks” very often.  I have something similar that I’ve rolled on my own that I use very rarely to decouple .dlls in .NET.  I’m not even sure that I would need something similar in Java because it has a different set of versioning problems.  Otherwise, I try to focus on good design.  TDD usually gives me all of the guidance I need there on what should vary and how it should be varied.

 

I have yet to need to cast any of the spells encoded into a dependency injection framework.

 

-- Max

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
Sent: Monday, February 01, 2010 12:28 AM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] Dependency Injection Frameworks

 

 

What is the take on these? When would you say "this project would benefit"?

A project would be taking on a respectible sized dependency just adding a DI framework (for example MS Unity). Given the size and complexity - I'm wondering if it is really worth it?

I don't have much experience using them, so maybe there is a big win that I have yet to see.

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.432 / Virus Database: 271.1.1/2658 - Release Date: 01/30/10 19:35:00


#774 From: Kim Gräsman <kim.grasman@...>
Date: Mon Feb 1, 2010 4:20 pm
Subject: Re: Re: ClassFactories vs dependancy injection
kimgrasman
Send Email Send Email
 
Hello,

On Mon, Feb 1, 2010 at 09:20, chrishand40 <cj.hand@...> wrote:
>
> It is a general question.
>
> I was reading around on the issue, and there is a strong push to favor DI over
class factories.  The thing that concerned me is the religiousness of it, as if
DI where the higher evolved form of coding.   Two reasons that I thought were
interesting are: 1) class factories violate the open / close principal, and 2)
Heavy use of class factories results in a lot of class factories in your
project.  Given how they are used, I'm not sure I care about #1, and at least in
the size of the projects I am doing, #2 hasn't been an issue.
>
> As I learned more, I realized I didn't really phrase the question well.  While
I have found dependency injection to be very useful when properly applied, my
larger concern is with the large and complex dependency injection frameworks.
 So far I've only worked on one project that used a framework and while I could
see some advantages - it wasn't done very well (IMO).  There was still a lot of
coupling in that if I wanted to change the source of data to be anything other
than a database it would involve a significant effort.  It also added a learning
curve just trying to understand what instances of which object would be created
when.
>
> So far, the answer I have gathered from the group is that it isn't an
either/or answer – they are different tools for different situations.

I don't have a clear opinion either way, but I read this the other
day, and it seems to touch on a couple of your concerns:
http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion

- Kim

#775 From: "e_renshaw" <e_renshaw@...>
Date: Tue Feb 2, 2010 7:18 pm
Subject: Re: Dependency Injection Frameworks
e_renshaw
Send Email Send Email
 
Very nice post Greg.

I would just put a word in for Unity, it actually does a nice job and I am
comfortable with the folks behind it knowing what they are talking about (Chris
Tavares last I heard).

The speed comparisons may be saying it's a bit of a dog but I haven't seen
anything that makes it a no go. I started with Spring and messed a little bit
with Windsor first and moved to Unity to get less hassle when deploying to
production (Microsoft and all). I have been very happy with the help
documentation as well.

Eric

--- In leanprogramming@yahoogroups.com, "gregbanister" <gregbanister@...> wrote:
>
>
> There are many good open source "DI frameworks" / "IOC Containers" (I probably
shouldn't, but I tend to use these two terms interchangeably) .  To name a few
in the .Net space there is Castle Windsor, StructureMap, NinJect, Autofac, and
more that you can see in this post
http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx
> At the risk of starting a flame war, I'll say that IMHO Unity is not one of
the "good" ones... "good" being very subjective.  I've been very happy with both
Castle and StructureMap.  NinJect and Autocac seem very popular although I
haven't used them yet, I plan to check them out.
>
> An IOC container helps me accomplish the following:
> 1) Test-Driven Development
> 2) Achieving low coupling in my designs
> 3) Application Configuration
> 4) Fine grain control over Object lifecycle
> 5) Decomposition in design (maybe this is the same as #2)
> 6) Making boundries explicit and intention revieling
>
> Note: This isn't an exahstive list of the benifist in using an IOC container,
it's just what quickly comes to mind.
>
> I'm sure you can do all of this without a DI framework / IOC container, but
the tool will make all of this a lot easier.
>
> In most situations, when you take on a "dependency just by adding a DI
framework", that dependency donsn't have to leak throuought your application. 
For instance, your entire application can be written without the knowledge of
any specific container or DI Framework accept for your the entry point where the
configuration of your dependencies are enacted (i.e. in Program.Main() or
Global.Application_Start()).  In most situations, by simply using constructor
injection, I'm able to keep the dependency on a container completely out of an
application except for the entry point.  If there are situations where you have
to access a container deep within your application to act as a "service broker",
then you can do so by providing your own static abastration over whatever
container you're using.  This (rare for me) situation makes for more friction
durring TDD, but it's realativly painless.
>
> I think 95% percent of the applications I write utilize a DI Framework / IOC
Container unless it's a very simple utility application that consists of a very
small amouont of classes (i.e. less than five) that I did not design using TDD.
>
> Greg
>
> --- In leanprogramming@yahoogroups.com, "chrishand40" <cj.hand@> wrote:
> >
> > What is the take on these?  When would you say "this project would benefit"?
> >
> > A project would be taking on a respectible sized dependency just adding a DI
framework (for example MS Unity).  Given the size and complexity - I'm wondering
if it is really worth it?
> >
> > I don't have much experience using them, so maybe there is a big win that I
have yet to see.
> >
>

#776 From: "Scott" <slbain@...>
Date: Sat Mar 13, 2010 9:16 pm
Subject: TDD Metrics
slbain9000
Send Email Send Email
 
Most TDD practitioners I've spoken with claim that teams that reach a matutity
with TDD enjoy an increase in productivity.  I have no trouble believing this,
but I wonder if there are any actual numbers on this?

Anyone have a credible study for me?  Most of the ones I've found online focus
on defect reduction and code quality.

#777 From: Otávio Macedo <otaviomacedo@...>
Date: Sat Mar 13, 2010 9:30 pm
Subject: Re: TDD Metrics
otaviomicrobio
Send Email Send Email
 
Here are some comments on this: http://www.agilemodeling.com/essays/proof.htm

On 13 March 2010 18:16, Scott <slbain@...> wrote:
 

Most TDD practitioners I've spoken with claim that teams that reach a matutity with TDD enjoy an increase in productivity. I have no trouble believing this, but I wonder if there are any actual numbers on this?

Anyone have a credible study for me? Most of the ones I've found online focus on defect reduction and code quality.




--
Otávio A. C. Macedo

#778 From: "Max Guernsey, III" <max@...>
Date: Sun Mar 14, 2010 8:31 am
Subject: RE: TDD Metrics
maxguernseyiii
Send Email Send Email
 

I think that such a study would be difficult to do in the current political climate as it could be impugned simply by not accepting the metrics used to prove the point…

 

If someone still believes there is such a thing as “code complete and ready for testing,” then they are looking at the world through a lens that will make TDD “slow them down.”  If they understand that only done is done, then they will be in a place where they can accept cycle time on whole units of value as the one true measure of capacity and, therefore, can accept that TDD improves their efficiency.

 

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott
Sent: Saturday, March 13, 2010 1:16 PM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] TDD Metrics

 

 

Most TDD practitioners I've spoken with claim that teams that reach a matutity with TDD enjoy an increase in productivity. I have no trouble believing this, but I wonder if there are any actual numbers on this?

Anyone have a credible study for me? Most of the ones I've found online focus on defect reduction and code quality.

Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10 07:34:00


#779 From: Alan Shalloway <alshall@...>
Date: Sun Mar 14, 2010 5:58 pm
Subject: RE: TDD Metrics
alshalloway
Send Email Send Email
 

You should check out Michael mah’s site at http://www.qsma.com/index.shtml

 

Alan Shalloway, CEO, Sr. Consultant, Net Objectives
Author of Lean-Agile Software Development, Design Patterns Explained, Lean-Agile Pocket Guide for Scrum Teams
425-269-8991 @alshalloway (twitter)

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott
Sent: Saturday, March 13, 2010 1:16 PM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] TDD Metrics

 

 

Most TDD practitioners I've spoken with claim that teams that reach a matutity with TDD enjoy an increase in productivity. I have no trouble believing this, but I wonder if there are any actual numbers on this?

Anyone have a credible study for me? Most of the ones I've found online focus on defect reduction and code quality.


#780 From: Scott Bain <slbain@...>
Date: Sun Mar 14, 2010 6:07 pm
Subject: RE: TDD Metrics
slbain9000
Send Email Send Email
 

I understand what you’re saying, Max, and insofar as we are talking “velocity”, I think you are right.

 

I think what I should have asked is:  are there any credible studies that show an increase in team productivity when TDD is used?  Velocity can be, as you point out, a rather misleading measurement.  One can move very quickly while doing the wrong thing, and producing waste, for instance.

 

-S-

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Max Guernsey, III
Sent: Sunday, March 14, 2010 12:32 AM
To: leanprogramming@yahoogroups.com
Subject: RE: [leanprogramming] TDD Metrics

 

 

I think that such a study would be difficult to do in the current political climate as it could be impugned simply by not accepting the metrics used to prove the point…

 

If someone still believes there is such a thing as “code complete and ready for testing,” then they are looking at the world through a lens that will make TDD “slow them down.”  If they understand that only done is done, then they will be in a place where they can accept cycle time on whole units of value as the one true measure of capacity and, therefore, can accept that TDD improves their efficiency.

 

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott
Sent: Saturday, March 13, 2010 1:16 PM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] TDD Metrics

 

 

Most TDD practitioners I've spoken with claim that teams that reach a matutity with TDD enjoy an increase in productivity. I have no trouble believing this, but I wonder if there are any actual numbers on this?

Anyone have a credible study for me? Most of the ones I've found online focus on defect reduction and code quality.

Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10 07:34:00


#781 From: Kim Gräsman <kim.grasman@...>
Date: Sun Mar 14, 2010 6:56 pm
Subject: Re: TDD Metrics
kimgrasman
Send Email Send Email
 
Hi Scott,

George Dinwiddie has a good set of refs at
http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment

Hope that helps,
- Kim

On Sat, Mar 13, 2010 at 22:16, Scott <slbain@...> wrote:
> Most TDD practitioners I've spoken with claim that teams that reach a matutity
with TDD enjoy an increase in productivity.  I have no trouble believing this,
but I wonder if there are any actual numbers on this?
>
> Anyone have a credible study for me?  Most of the ones I've found online focus
on defect reduction and code quality.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

#782 From: "chrishand40" <cj.hand@...>
Date: Sun Mar 14, 2010 9:54 pm
Subject: Re: TDD Metrics
chrishand40
Send Email Send Email
 
TDD ... now with 40% more productivity!

(Oh, and the short answer is no, I don't know of any report I would respect that
says TDD is more productive that some other approach)

Your question made me wonder, what is "productivity"?  From Wikipedia,
"Productivity is a measure of output from a production process, per unit of
input."  To me this means that for you to have a credible study, the study would
have to measure the ins and outs the same way you do.

I've done a lot of personal experimentation.  If you apply TDD to a very short
term project (a day or two), then it ALWAYS takes longer than someone that just
"bangs out the code".

For me, the value of TDD came in when that short term project starts to take on
a life of its own – when the customer comes back and wants new or different
functionality.  Again, through personal experimentation I found that TDD forced
a style of coding that made shifting requirements much simpler to adapt to.

I also find that the longer I work on a project, the more I see patterns emerge
from the code.  When I do TDD, it is more practical to factor out these patterns
because I have tests that verify the expectations of the code are still being
met.  In code that TDD has not been practiced, I find there is a lot of
repetitive code that people are afraid to touch because no-one knows what it is
being used for.

So after thinking through this, if "productivity" were measured by the amount of
code written to meet the requirements of a customer – then it seems the easiest
way to prove it would be to run through use-case scenarios while monitoring code
coverage.  My hypothesis would be that as the number of requirements increase:
1) when using TDD, you would see less code required to fulfill the needs of the
requirements and 2) when using TDD, there would be a smaller amount of "dead"
code when running through the user scenarios.

I know I didn't answer the question, but thanks for asking it - I did enjoy
thinking through what the answer might look like.  I hope it makes sense.



--- In leanprogramming@yahoogroups.com, "Scott" <slbain@...> wrote:
>
> Most TDD practitioners I've spoken with claim that teams that reach a matutity
with TDD enjoy an increase in productivity.  I have no trouble believing this,
but I wonder if there are any actual numbers on this?
>
> Anyone have a credible study for me?  Most of the ones I've found online focus
on defect reduction and code quality.
>

#783 From: "Max Guernsey, III" <max@...>
Date: Mon Mar 15, 2010 1:46 am
Subject: RE: TDD Metrics
maxguernseyiii
Send Email Send Email
 

I just don’t get how you can show the increase in productivity without measuring velocity and, as soon as that measurement comes into play, I think it opens up the argument for “debate.”  I’ll be interested in hearing how referring to these studies serves you is, I guess, what I’m really saying.

 

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott Bain
Sent: Sunday, March 14, 2010 11:07 AM
To: leanprogramming@yahoogroups.com
Subject: RE: [leanprogramming] TDD Metrics

 

 

I understand what you’re saying, Max, and insofar as we are talking “velocity”, I think you are right.

 

I think what I should have asked is:  are there any credible studies that show an increase in team productivity when TDD is used?  Velocity can be, as you point out, a rather misleading measurement.  One can move very quickly while doing the wrong thing, and producing waste, for instance.

 

-S-

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Max Guernsey, III
Sent: Sunday, March 14, 2010 12:32 AM
To: leanprogramming@yahoogroups.com
Subject: RE: [leanprogramming] TDD Metrics

 

 

I think that such a study would be difficult to do in the current political climate as it could be impugned simply by not accepting the metrics used to prove the point…

 

If someone still believes there is such a thing as “code complete and ready for testing,” then they are looking at the world through a lens that will make TDD “slow them down.”  If they understand that only done is done, then they will be in a place where they can accept cycle time on whole units of value as the one true measure of capacity and, therefore, can accept that TDD improves their efficiency.

 

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott
Sent: Saturday, March 13, 2010 1:16 PM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] TDD Metrics

 

 

Most TDD practitioners I've spoken with claim that teams that reach a matutity with TDD enjoy an increase in productivity. I have no trouble believing this, but I wonder if there are any actual numbers on this?

Anyone have a credible study for me? Most of the ones I've found online focus on defect reduction and code quality.

Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10 07:34:00

Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10 07:34:00


#784 From: "Max Guernsey, III" <max@...>
Date: Mon Mar 15, 2010 1:51 am
Subject: RE: Re: TDD Metrics
maxguernseyiii
Send Email Send Email
 

See, I disagree with the “ALWAYS takes longer than someone that just ‘bangs out the code’” statement… or at least I’ve had different experiences.

 

The code can be “done” in a shorter time without TDD so long as your definition of “done” doesn’t have anything to do with real doneness.  I’ve never seen a project of any reasonable length (more than Console.WriteLine("{0} + {1} = {2}", 1, 2, 3);) that can be actually completed more quickly by “banging it out” than by using TDD.

 

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
Sent: Sunday, March 14, 2010 2:54 PM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] Re: TDD Metrics

 

 

TDD ... now with 40% more productivity!

(Oh, and the short answer is no, I don't know of any report I would respect that says TDD is more productive that some other approach)

Your question made me wonder, what is "productivity"? From Wikipedia, "Productivity is a measure of output from a production process, per unit of input." To me this means that for you to have a credible study, the study would have to measure the ins and outs the same way you do.

I've done a lot of personal experimentation. If you apply TDD to a very short term project (a day or two), then it ALWAYS takes longer than someone that just "bangs out the code".

For me, the value of TDD came in when that short term project starts to take on a life of its own – when the customer comes back and wants new or different functionality. Again, through personal experimentation I found that TDD forced a style of coding that made shifting requirements much simpler to adapt to.

I also find that the longer I work on a project, the more I see patterns emerge from the code. When I do TDD, it is more practical to factor out these patterns because I have tests that verify the expectations of the code are still being met. In code that TDD has not been practiced, I find there is a lot of repetitive code that people are afraid to touch because no-one knows what it is being used for.

So after thinking through this, if "productivity" were measured by the amount of code written to meet the requirements of a customer – then it seems the easiest way to prove it would be to run through use-case scenarios while monitoring code coverage. My hypothesis would be that as the number of requirements increase: 1) when using TDD, you would see less code required to fulfill the needs of the requirements and 2) when using TDD, there would be a smaller amount of "dead" code when running through the user scenarios.

I know I didn't answer the question, but thanks for asking it - I did enjoy thinking through what the answer might look like. I hope it makes sense.

--- In leanprogramming@yahoogroups.com, "Scott" <slbain@...> wrote:
>
> Most TDD practitioners I've spoken with claim that teams that reach a matutity with TDD enjoy an increase in productivity. I have no trouble believing this, but I wonder if there are any actual numbers on this?
>
> Anyone have a credible study for me? Most of the ones I've found online focus on defect reduction and code quality.
>

Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10 07:34:00


#785 From: "chrishand40" <cj.hand@...>
Date: Mon Mar 15, 2010 2:40 am
Subject: Re: TDD Metrics
chrishand40
Send Email Send Email
 
Personal experience:  I created a set of webapi's that provided a set of
functionality.  I was then asked to create a simple tool that used the webapis
for a user to pull some data down based on a simple input.  In less than 10
lines of code I created a tool that met the provided requirements.  I could have
done TDD, but I would have done more effort and not gained anything for it.


--- In leanprogramming@yahoogroups.com, "Max Guernsey, III" <max@...> wrote:
>
> See, I disagree with the "ALWAYS takes longer than someone that just 'bangs
> out the code'" statement. or at least I've had different experiences.
>
>
>
> The code can be "done" in a shorter time without TDD so long as your
> definition of "done" doesn't have anything to do with real doneness.  I've
> never seen a project of any reasonable length (more than
> Console.WriteLine("{0} + {1} = {2}", 1, 2, 3);) that can be actually
> completed more quickly by "banging it out" than by using TDD.
>
>
>
> Max Guernsey, III
>
>
>
>  <http://www.informit.com/store/product.aspx?isbn=032163604X> Transition
> Testing: Cornerstone of Database Agility
>
>
> <http://www.lulu.com/content/paperback-book/goad-testing-deepening-our-under
> standing-of-automated-tests/8372524> Goad Testing: Deepening our
> Understanding of Automated Tests
>
>  <http://www.dataconstructor.com/> http://www.dataconstructor.com
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
> Sent: Sunday, March 14, 2010 2:54 PM
> To: leanprogramming@yahoogroups.com
> Subject: [leanprogramming] Re: TDD Metrics
>
>
>
>
>
> TDD ... now with 40% more productivity!
>
> (Oh, and the short answer is no, I don't know of any report I would respect
> that says TDD is more productive that some other approach)
>
> Your question made me wonder, what is "productivity"? From Wikipedia,
> "Productivity is a measure of output from a production process, per unit of
> input." To me this means that for you to have a credible study, the study
> would have to measure the ins and outs the same way you do.
>
> I've done a lot of personal experimentation. If you apply TDD to a very
> short term project (a day or two), then it ALWAYS takes longer than someone
> that just "bangs out the code".
>
> For me, the value of TDD came in when that short term project starts to take
> on a life of its own - when the customer comes back and wants new or
> different functionality. Again, through personal experimentation I found
> that TDD forced a style of coding that made shifting requirements much
> simpler to adapt to.
>
> I also find that the longer I work on a project, the more I see patterns
> emerge from the code. When I do TDD, it is more practical to factor out
> these patterns because I have tests that verify the expectations of the code
> are still being met. In code that TDD has not been practiced, I find there
> is a lot of repetitive code that people are afraid to touch because no-one
> knows what it is being used for.
>
> So after thinking through this, if "productivity" were measured by the
> amount of code written to meet the requirements of a customer - then it
> seems the easiest way to prove it would be to run through use-case scenarios
> while monitoring code coverage. My hypothesis would be that as the number of
> requirements increase: 1) when using TDD, you would see less code required
> to fulfill the needs of the requirements and 2) when using TDD, there would
> be a smaller amount of "dead" code when running through the user scenarios.
>
> I know I didn't answer the question, but thanks for asking it - I did enjoy
> thinking through what the answer might look like. I hope it makes sense.
>
> --- In leanprogramming@yahoogroups.com
> <mailto:leanprogramming%40yahoogroups.com> , "Scott" <slbain@> wrote:
> >
> > Most TDD practitioners I've spoken with claim that teams that reach a
> matutity with TDD enjoy an increase in productivity. I have no trouble
> believing this, but I wonder if there are any actual numbers on this?
> >
> > Anyone have a credible study for me? Most of the ones I've found online
> focus on defect reduction and code quality.
> >
>
>
>
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
> 07:34:00
>

#786 From: "chrishand40" <cj.hand@...>
Date: Mon Mar 15, 2010 3:13 am
Subject: Re: TDD Metrics
chrishand40
Send Email Send Email
 
I thought about this ...

If you have two teams, one doing TDD and one that isn't.  The way they estimate
could make one appear to have a higher velocity then the other.  If one team
were more suited to the work, that team might show a higher velocity.  It is too
smushy of a metric to be used as anything other than what it was meant for.

The more I think about it, the more I don't like thinking about TDD as a process
to increase productivity in terms of time.  While I do believe it is true -
especially in larger projects, I think it is like trying to prove the state of
Schrödinger's cat.




--- In leanprogramming@yahoogroups.com, "Max Guernsey, III" <max@...> wrote:
>
> I just don't get how you can show the increase in productivity without
> measuring velocity and, as soon as that measurement comes into play, I think
> it opens up the argument for "debate."  I'll be interested in hearing how
> referring to these studies serves you is, I guess, what I'm really saying.
>
>
>
> Max Guernsey, III
>
>
>
>  <http://www.informit.com/store/product.aspx?isbn=032163604X> Transition
> Testing: Cornerstone of Database Agility
>
>
> <http://www.lulu.com/content/paperback-book/goad-testing-deepening-our-under
> standing-of-automated-tests/8372524> Goad Testing: Deepening our
> Understanding of Automated Tests
>
>  <http://www.dataconstructor.com/> http://www.dataconstructor.com
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott Bain
> Sent: Sunday, March 14, 2010 11:07 AM
> To: leanprogramming@yahoogroups.com
> Subject: RE: [leanprogramming] TDD Metrics
>
>
>
>
>
> I understand what you're saying, Max, and insofar as we are talking
> "velocity", I think you are right.
>
>
>
> I think what I should have asked is:  are there any credible studies that
> show an increase in team productivity when TDD is used?  Velocity can be, as
> you point out, a rather misleading measurement.  One can move very quickly
> while doing the wrong thing, and producing waste, for instance.
>
>
>
> -S-
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of Max Guernsey, III
> Sent: Sunday, March 14, 2010 12:32 AM
> To: leanprogramming@yahoogroups.com
> Subject: RE: [leanprogramming] TDD Metrics
>
>
>
>
>
> I think that such a study would be difficult to do in the current political
> climate as it could be impugned simply by not accepting the metrics used to
> prove the point.
>
>
>
> If someone still believes there is such a thing as "code complete and ready
> for testing," then they are looking at the world through a lens that will
> make TDD "slow them down."  If they understand that only done is done, then
> they will be in a place where they can accept cycle time on whole units of
> value as the one true measure of capacity and, therefore, can accept that
> TDD improves their efficiency.
>
>
>
> Max Guernsey, III
>
>
>
>  <http://www.informit.com/store/product.aspx?isbn=032163604X> Transition
> Testing: Cornerstone of Database Agility
>
>
> <http://www.lulu.com/content/paperback-book/goad-testing-deepening-our-under
> standing-of-automated-tests/8372524> Goad Testing: Deepening our
> Understanding of Automated Tests
>
>  <http://www.dataconstructor.com/> http://www.dataconstructor.com
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott
> Sent: Saturday, March 13, 2010 1:16 PM
> To: leanprogramming@yahoogroups.com
> Subject: [leanprogramming] TDD Metrics
>
>
>
>
>
> Most TDD practitioners I've spoken with claim that teams that reach a
> matutity with TDD enjoy an increase in productivity. I have no trouble
> believing this, but I wonder if there are any actual numbers on this?
>
> Anyone have a credible study for me? Most of the ones I've found online
> focus on defect reduction and code quality.
>
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
> 07:34:00
>
>
>
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
> 07:34:00
>

#787 From: "Max Guernsey, III" <max@...>
Date: Mon Mar 15, 2010 6:45 am
Subject: RE: Re: TDD Metrics
maxguernseyiii
Send Email Send Email
 

Ten lines of code is a lot closer to the trivial example I gave than it is to a two day project.  I’m not saying that there aren’t a handful of exceptional cases in which TDD costs more than not doing it.  I’m just not agreeing that there are scenarios in which it “always” costs more.

 

If you are doing it right, it shouldn’t cost any more anyway.  You breath while you work and that doesn’t cost you anything extra.

 

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
Sent: Sunday, March 14, 2010 7:41 PM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] Re: TDD Metrics

 

 

Personal experience: I created a set of webapi's that provided a set of functionality. I was then asked to create a simple tool that used the webapis for a user to pull some data down based on a simple input. In less than 10 lines of code I created a tool that met the provided requirements. I could have done TDD, but I would have done more effort and not gained anything for it.

--- In leanprogramming@yahoogroups.com, "Max Guernsey, III" <max@...> wrote:
>
> See, I disagree with the "ALWAYS takes longer than someone that just 'bangs
> out the code'" statement. or at least I've had different experiences.
>
>
>
> The code can be "done" in a shorter time without TDD so long as your
> definition of "done" doesn't have anything to do with real doneness. I've
> never seen a project of any reasonable length (more than
> Console.WriteLine("{0} + {1} = {2}", 1, 2, 3);) that can be actually
> completed more quickly by "banging it out" than by using TDD.
>
>
>
> Max Guernsey, III
>
>
>
> <http://www.informit.com/store/product.aspx?isbn=032163604X> Transition
> Testing: Cornerstone of Database Agility
>
>
> <http://www.lulu.com/content/paperback-book/goad-testing-deepening-our-under
> standing-of-automated-tests/8372524> Goad Testing: Deepening our
> Understanding of Automated Tests
>
> <http://www.dataconstructor.com/> http://www.dataconstructor.com
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
> Sent: Sunday, March 14, 2010 2:54 PM
> To: leanprogramming@yahoogroups.com
> Subject: [leanprogramming] Re: TDD Metrics
>
>
>
>
>
> TDD ... now with 40% more productivity!
>
> (Oh, and the short answer is no, I don't know of any report I would respect
> that says TDD is more productive that some other approach)
>
> Your question made me wonder, what is "productivity"? From Wikipedia,
> "Productivity is a measure of output from a production process, per unit of
> input." To me this means that for you to have a credible study, the study
> would have to measure the ins and outs the same way you do.
>
> I've done a lot of personal experimentation. If you apply TDD to a very
> short term project (a day or two), then it ALWAYS takes longer than someone
> that just "bangs out the code".
>
> For me, the value of TDD came in when that short term project starts to take
> on a life of its own - when the customer comes back and wants new or
> different functionality. Again, through personal experimentation I found
> that TDD forced a style of coding that made shifting requirements much
> simpler to adapt to.
>
> I also find that the longer I work on a project, the more I see patterns
> emerge from the code. When I do TDD, it is more practical to factor out
> these patterns because I have tests that verify the expectations of the code
> are still being met. In code that TDD has not been practiced, I find there
> is a lot of repetitive code that people are afraid to touch because no-one
> knows what it is being used for.
>
> So after thinking through this, if "productivity" were measured by the
> amount of code written to meet the requirements of a customer - then it
> seems the easiest way to prove it would be to run through use-case scenarios
> while monitoring code coverage. My hypothesis would be that as the number of
> requirements increase: 1) when using TDD, you would see less code required
> to fulfill the needs of the requirements and 2) when using TDD, there would
> be a smaller amount of "dead" code when running through the user scenarios.
>
> I know I didn't answer the question, but thanks for asking it - I did enjoy
> thinking through what the answer might look like. I hope it makes sense.
>
> --- In leanprogramming@yahoogroups.com
> <mailto:leanprogramming%40yahoogroups.com> , "Scott" <slbain@> wrote:
> >
> > Most TDD practitioners I've spoken with claim that teams that reach a
> matutity with TDD enjoy an increase in productivity. I have no trouble
> believing this, but I wonder if there are any actual numbers on this?
> >
> > Anyone have a credible study for me? Most of the ones I've found online
> focus on defect reduction and code quality.
> >
>
>
>
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
> 07:34:00
>

Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10 07:34:00


#788 From: "Max Guernsey, III" <max@...>
Date: Mon Mar 15, 2010 6:45 am
Subject: RE: Re: TDD Metrics
maxguernseyiii
Send Email Send Email
 

Certainly that’s an important perspective and one that is all too often ignored.  Though I should point out that not knowing the state of the cat is what tends to cause things to take the most time and, therefore, to hurt productivity…

 

If “velocity” is “complexity overcome” as would be measured by using story points estimated by a team, then yeah… you’re screwed.  If velocity is “units of business value delivered” as estimated by product sponsors, it’s a little better.  Still, teams that have terrible practices are masters at making their velocity look high while they are “competing.”

 

I’ve actually been in that exact scenario.  The team with the terrible practices “proved” that our processes were wasteful by “delivering” a bunch of garbage quickly.  If you guys are reading, you know who you are.  They kept their project on life support until management rendered it’s judgment and canceled Agility at that department.  When it hit the fan, the problems were seen as “normal.”

 

…a man convinced against his will…

 

 

From: leanprogramming@yahoogroups.com [mailto:leanprogramming@yahoogroups.com] On Behalf Of chrishand40
Sent: Sunday, March 14, 2010 8:13 PM
To: leanprogramming@yahoogroups.com
Subject: [leanprogramming] Re: TDD Metrics

 

 

I thought about this ...

If you have two teams, one doing TDD and one that isn't. The way they estimate could make one appear to have a higher velocity then the other. If one team were more suited to the work, that team might show a higher velocity. It is too smushy of a metric to be used as anything other than what it was meant for.

The more I think about it, the more I don't like thinking about TDD as a process to increase productivity in terms of time. While I do believe it is true - especially in larger projects, I think it is like trying to prove the state of Schrödinger's cat.

--- In leanprogramming@yahoogroups.com, "Max Guernsey, III" <max@...> wrote:
>
> I just don't get how you can show the increase in productivity without
> measuring velocity and, as soon as that measurement comes into play, I think
> it opens up the argument for "debate." I'll be interested in hearing how
> referring to these studies serves you is, I guess, what I'm really saying.
>
>
>
> Max Guernsey, III
>
>
>
> <http://www.informit.com/store/product.aspx?isbn=032163604X> Transition
> Testing: Cornerstone of Database Agility
>
>
> <http://www.lulu.com/content/paperback-book/goad-testing-deepening-our-under
> standing-of-automated-tests/8372524> Goad Testing: Deepening our
> Understanding of Automated Tests
>
> <http://www.dataconstructor.com/> http://www.dataconstructor.com
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott Bain
> Sent: Sunday, March 14, 2010 11:07 AM
> To: leanprogramming@yahoogroups.com
> Subject: RE: [leanprogramming] TDD Metrics
>
>
>
>
>
> I understand what you're saying, Max, and insofar as we are talking
> "velocity", I think you are right.
>
>
>
> I think what I should have asked is: are there any credible studies that
> show an increase in team productivity when TDD is used? Velocity can be, as
> you point out, a rather misleading measurement. One can move very quickly
> while doing the wrong thing, and producing waste, for instance.
>
>
>
> -S-
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of Max Guernsey, III
> Sent: Sunday, March 14, 2010 12:32 AM
> To: leanprogramming@yahoogroups.com
> Subject: RE: [leanprogramming] TDD Metrics
>
>
>
>
>
> I think that such a study would be difficult to do in the current political
> climate as it could be impugned simply by not accepting the metrics used to
> prove the point.
>
>
>
> If someone still believes there is such a thing as "code complete and ready
> for testing," then they are looking at the world through a lens that will
> make TDD "slow them down." If they understand that only done is done, then
> they will be in a place where they can accept cycle time on whole units of
> value as the one true measure of capacity and, therefore, can accept that
> TDD improves their efficiency.
>
>
>
> Max Guernsey, III
>
>
>
> <http://www.informit.com/store/product.aspx?isbn=032163604X> Transition
> Testing: Cornerstone of Database Agility
>
>
> <http://www.lulu.com/content/paperback-book/goad-testing-deepening-our-under
> standing-of-automated-tests/8372524> Goad Testing: Deepening our
> Understanding of Automated Tests
>
> <http://www.dataconstructor.com/> http://www.dataconstructor.com
>
>
>
> From: leanprogramming@yahoogroups.com
> [mailto:leanprogramming@yahoogroups.com] On Behalf Of Scott
> Sent: Saturday, March 13, 2010 1:16 PM
> To: leanprogramming@yahoogroups.com
> Subject: [leanprogramming] TDD Metrics
>
>
>
>
>
> Most TDD practitioners I've spoken with claim that teams that reach a
> matutity with TDD enjoy an increase in productivity. I have no trouble
> believing this, but I wonder if there are any actual numbers on this?
>
> Anyone have a credible study for me? Most of the ones I've found online
> focus on defect reduction and code quality.
>
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
> 07:34:00
>
>
>
> Internal Virus Database is out of date.
> Checked by AVG - www.avg.com
> Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
> 07:34:00
>

Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10 07:34:00


#789 From: Raoul Duke <raould@...>
Date: Mon Mar 15, 2010 6:29 pm
Subject: Re: Re: TDD Metrics
theraoulduke
Send Email Send Email
 
On Sun, Mar 14, 2010 at 11:45 PM, Max Guernsey, III <max@...> wrote:
> I’ve actually been in that exact scenario.  The team with the terrible
practices “proved” that our processes were wasteful by “delivering” a bunch of
garbage quickly.  If you guys are reading, you know who you are.  They kept
their project on life support until management rendered it’s judgment and
canceled Agility at that department.  When it hit the fan, the problems were
seen as “normal.”

a moment of silence for that playing out ever over across the globe...

#790 From: "Max Guernsey, III" <max@...>
Date: Tue Mar 16, 2010 3:15 am
Subject: RE: Re: TDD Metrics
maxguernseyiii
Send Email Send Email
 
Yep.  Sad but seemingly commonplace.

They don't actually burn us at the stake anymore but things haven't changed
much in the last five-hundred years.

Max Guernsey, III

Transition Testing: Cornerstone of Database Agility
Goad Testing: Deepening our Understanding of Automated Tests
http://www.dataconstructor.com

-----Original Message-----
From: leanprogramming@yahoogroups.com
[mailto:leanprogramming@yahoogroups.com] On Behalf Of Raoul Duke
Sent: Monday, March 15, 2010 11:30 AM
To: leanprogramming@yahoogroups.com
Subject: Re: [leanprogramming] Re: TDD Metrics

On Sun, Mar 14, 2010 at 11:45 PM, Max Guernsey, III <max@...> wrote:
> I’ve actually been in that exact scenario.  The team with the terrible
practices “proved” that our processes were wasteful by “delivering” a bunch
of garbage quickly.  If you guys are reading, you know who you are.  They
kept their project on life support until management rendered it’s judgment
and canceled Agility at that department.  When it hit the fan, the problems
were seen as “normal.”

a moment of silence for that playing out ever over across the globe...


------------------------------------

Yahoo! Groups Links



Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.435 / Virus Database: 271.1.1/2714 - Release Date: 02/28/10
07:34:00

#791 From: "Scott" <slbain@...>
Date: Fri Mar 19, 2010 5:59 pm
Subject: Thanks!
slbain9000
Send Email Send Email
 
I just wanted to say thanks to everyone who responded to my TDD Metrics
question.  Very interesting and useful responses. :)

#792 From: "Scott" <slbain@...>
Date: Tue Apr 20, 2010 8:04 pm
Subject: Could use some opinions
slbain9000
Send Email Send Email
 
One thing I've been tasked to do is create a recorded edicational series
designed to help procedural programmers make the transition to objects.  Some
organizations have devs who are still focues on procedural technique, and want
to find ways to get them to "switch over" to the OO mindset, but can run into
resistence.

So, this is the first of six recordings designed not only to clarify the
difference between procedural approach and OO, but also to create some
motivation for, say, a very seasoned and talented Cobol programmer to be willing
to make a significant change to the way he or she works:

http://www.netobjectives.com/files/WhyHowObjects/SessionOnePartOne/SessionOnePar\
tOne.html

Note, most of the people in this group are *not* the target audience here, but
might have some thoughts on whether my approach is going to do what I hope.

Any opinions would be greatly appreciated.

#793 From: Raoul Duke <raould@...>
Date: Tue Apr 20, 2010 9:47 pm
Subject: Re: Could use some opinions
theraoulduke
Send Email Send Email
 
On Tue, Apr 20, 2010 at 1:04 PM, Scott <slbain@...> wrote:
>
http://www.netobjectives.com/files/WhyHowObjects/SessionOnePartOne/SessionOnePar\
tOne.html

i'm not the target audience, so my reaction might not count, but...

teaching something is hard. each audience member probably learns in a
different way. for myself, i like to have more of a light theoretical
explanation, something along the lines of the Expression or
Extensibility Problem cf.
http://lambda-the-ultimate.org/node/3600#comment-51050

listening to WhyHowObjects S1P1, it is too hand-wavey loosey goosey
for me. having said that, if i imagine some really crochety grizzled
stuck in the mud coboalistaz, i can see how the presentation could be
a good hook. :-)

sincerely.

Messages 764 - 793 of 940   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help