Comments on: Avatars of TDD http://blogs.agilefaqs.com/2007/12/14/avatars-of-tdd/ Naresh Jain's Random Thoughts on Software Development and Adventure Sports Tue, 10 Jan 2012 14:24:00 +0000 hourly 1 http://wordpress.org/?v= By: Naresh Jain http://blogs.agilefaqs.com/2007/12/14/avatars-of-tdd/comment-page-1/#comment-13295 Naresh Jain Sun, 31 Aug 2008 12:46:29 +0000 http://blogs.agilefaqs.com/2007/12/14/avatars-of-tdd/#comment-13295 Great observation Kevin. What I find on most successful projects is developers constantly swap between Outside-In and Inside-Out approach. Great observation Kevin. What I find on most successful projects is developers constantly swap between Outside-In and Inside-Out approach.

]]> By: Kevin Miller http://blogs.agilefaqs.com/2007/12/14/avatars-of-tdd/comment-page-1/#comment-6627 Kevin Miller Sun, 06 Jan 2008 19:55:19 +0000 http://blogs.agilefaqs.com/2007/12/14/avatars-of-tdd/#comment-6627 Interesting observation. When I was first learning to practice TDD I was admonished to use the Inside-Out Avatar. I didn't realize there was a choice. After practicing for some time I find myself behaving in a more Outside-In way all the while feeling guilty that "I was doing it wrong". To me at times the Inside-Out avatar seems to lead to what I would consider over-engineered solutions. The code starts out very factored but it feels like it takes longer to get to some working code and the outcome sometimes has abstractions that are not strictly necessary for the task at hand. When using a more Outside-In technique I found myself trying to get a sample of the behavior I desired done early. Then refactor the code to clean up any shortcuts or narrowness that is present. The best code I have seen comes from when both avatars are allowed to go head to head and compromise. Interesting observation. When I was first learning to practice TDD I was admonished to use the Inside-Out Avatar. I didn’t realize there was a choice. After practicing for some time I find myself behaving in a more Outside-In way all the while feeling guilty that “I was doing it wrong”.

To me at times the Inside-Out avatar seems to lead to what I would consider over-engineered solutions. The code starts out very factored but it feels like it takes longer to get to some working code and the outcome sometimes has abstractions that are not strictly necessary for the task at hand.

When using a more Outside-In technique I found myself trying to get a sample of the behavior I desired done early. Then refactor the code to clean up any shortcuts or narrowness that is present.

The best code I have seen comes from when both avatars are allowed to go head to head and compromise.

]]>