Jimmy just wrote a post on one of the "problems" with DDD to quote him:

"Even though DDD in itself isn't at all new, it's new to those that haven't tried it before, of course. And if you work in a big team with no prior experience of DDD, then it's very risky using it for a new and time constrained project. There are ways of reducing the risk, but it's still there and it's real."

It's a really interesting point of view and one I as a coach and instructor has runned into a lot of times and I think it ties into my earlier post about features being to complex for some developers.

Any new methodology, practice or technology is bound to be difficult in the beginning and as one will very quickly realize is that just because it works for the other teams product or the cool speaker on stage it might not work for me. These failures is more often then not a result of a cargo cult thinking where a team picks up a set of skills from someone else and just tries to copy the success.

It will almost always fail and that is what brings in the risk in the project. When you want to introduce something new in a live project you need experience, at least some experience mixed in with the "new guys".

There is several ways to get that experience into the project, you could hire someone like Cornerstone's coaches, Jimmy or other factor10 consultants to hold your hand through your first baby steps or you can make sure that your team has time to practice new skills (or combine both).

To practice I like to use Code Katas which let's me practice my skills over and over again on the exact same scenario. Allowing me to refine certain aspects of the piece of technology or methodology I'm pursuing.

Doing these practices will give you a more thorough understanding of what the "other guys" are doing and that understanding will eliminate some of the risk, reduce the overhead in real projects to introduce new things and eliminate the cargo cult thinking since now you can take informed decisions from your own past experience.

Oh, and the added benefit of doing these practices together in your team is that all will share a common viewpoint on how code should be written and competence transfer during one of these coding dojos is extremely high.

So, as any other thing in life; take time to practice a lot, practice alone and practice in group before you try the "real deal" and the risks will be minimized.

... no matter what fancy technology you use.

A question that arise often is when and where to use anonymous methods (or lambdas) where a delegate is expected. Anonymous methods and lambdas is a really nice way to quickly pass in a piece of code where a function pointer is expected.

Quick but sometimes very, very dirty.

To avoid opacity you need to make sure that the anonymous method is clear in it's intent and is easy to understand and read. That's why they are great for one-liners (maybe two or three) but start to get messy when you add more. So a thumb of rule is, if the method intention isn't clear, apply "extract method" and name the method to clearly show intent instead.

To avoid needless repetition you apply the same refactoring. E.G if you discover that a piece of code is re-used over and over, just refactor it to a method with a name that's clear about it's intention.

Also, make sure it's forbidden to copy code and that if anyone want's to reuse some code that's already written they should extract it to a method. The "no copy paste" rule often makes it easier to not fall into "needless repetition" even for anonymous methods.

One of the most adverse argument to not explore new technology, methodology or principles is the false alibi of "complexity makes it harder to staff our project".

This is an overused argument in many cases, a solid one in some. Bot the solid and overused cases has one thing in common, clients listens to the argument with full attention. You don't want an understaffed project.But that makes the argument so much more dangerous and one that you should watch out for.

I for one would like to argue that it's more often used as an alibi for developers that don't want to improve their skills, that don't want to learn new stuff and don't want the old ways to change.

If a piece of technology, methodology or principle gives you a benefit. Use it and educate your team, don't stay away from it. In my book, not evolving the team is the same thing as devolving them.

I've had the good fortune to listen to Dan North a couple of times, formally and informally, when he talks about his passion, BDD. Even though I've heard him many times explain the concept, read numerous posts and played around with it, I can't say that I grasp the full story yet. But some things I do get.

First of all, there is a diversity in the BDD community on what it really means. In one corner there is the initial ideas from Dan and in the other corner there is variations of the concepts like SpecUnit from Scott Bellware.

But the basic idea is the same: Wording is important.

Dan derives his work from one of his greatest fascinations, Neuro-lingustic  programming (NLP) where words are used in a communication to trigger responses and effects from a party. His fascination with NLP in combination with having to explain TDD over and over again made him think about the wording and made him think about how words are important when building test-first kind of applications.

One of the words that is important is "Test" as in "Test Driven Development" where people often associate testing as something that is done after development. This is one of the controversies when it comes to selling TDD to the masses, "How can I write my test when I don't have something TO test".

Changing the name from "test" to "specification" or "behavior" will probably level the field.

Everyone specifies behavior of what they want before they try to build it (well almost everyone) so SDD, specification driven development, or as it's called BDD, will make more sense to people and is something they can relate other activities to.

This is where I think that the TDD community would do themselves a big favor if they started talking more about "specifying what the completed code should do", rather then "writing tests for the completed code before completing the code".

The BDD community talks a lot about wording in other senses as well. Dan for instance wants developers to make sure that the tests are complete sentences and sentences that matches requirements from the business. For instance:

Account_Should_Be_debited_Given_The_Account_Is_In_Credit_When_Customer_Requires_Cash

Is a name inspired by his "Given, When, Then" template for behavior specification.

To support this kind of naming scheme, the names tend to get long, projects has started, like the mentioned SpecUnit, RBehave, JBehave and NBehave. This is what the community is thinking about now. To support this new style of development we need new tools, the old once support TDD and not BDD and how should those tools look like?

So is BDD a hype or a paradigm shift? I believe it's the latter, I think that what the BDD and various spec* communities has started is an inevitable change of the "test-first" kind of coding. We see some small ripples now in how people design their tests but give it time and we'll see big changes in tooling and methodology. 

--

NLP: http://en.wikipedia.org/wiki/Neuro-linguistic_programming

Merlin's magic spells in modern projects: https://lowendahl.net/showShout.aspx?id=200

Dan's "Introducing BDD": http://dannorth.net/introducing-bdd

Scott on BDD: http://www.code-magazine.com/Article.aspx?quickid=0805061

JBehave: http://jbehave.org/

NBehace: http://nbehave.org/

Rbehave: http://dannorth.net/2007/06/introducing-rbehave

The last couple of years I've been using TDD as my main philosophy when writing code. In the beginning I was really static in my testing, everything was tested in isolation, but over time I've become more pragmatic and realized that some things are just not meant to be tested isolated.

I've discovered that the Repository is such a thing.

At least my Repositories work a lot with the infrastructure layer and not much else. So to test those in isolation I need to mock the infrastructure used by the repositories. The question the is, what Am I really testing?

Consider this, simple, method in the repository (using LINQ to SQL):

        public List ListProductsFilteredOnName(string nameFilter) 
        {
            var filteredProductsQuery = from item in context.GetTable()
                                        where item.Name.IndexOf(nameFilter) > 0
                                        select item;

            return filteredProductsQuery.ToList();
        }

If I mocked the infrastructure in this case, what would I really test?

I would test the usage of the infrastructure exactly as expected, not that the method behaves as expected. Who really cares how the infrastructure is used as long as the function behaves accordingly?

So if I want to test the behavior of this method, I will need to involve the real infrastructure and access the store. E.g I would resort to only test the repository with integration tests, not unit tests.

Now, there is a couple of test I might want to do in these scenarios, like checking that expected exceptions are thrown. But all and all, the behavior of the repository is really based on what it does together with the store.

So in conclusion, make sure that you have enough test coverage. But refrain from taking the isolation to places where it just don't make sense.

--

More on repositories: http://www.martinfowler.com/eaaCatalog/repository.html
More on TDD: http://en.wikipedia.org/wiki/Test-driven_development

1. Never write a single line of code if you don't have a failing automated test
2. Eliminate duplication

So TDD is storming the .NET waters. Even Microsoft is talking about TDD in their upcoming Visual Studio Team System release (though Jimmy Nilsson claims it's not really TDD). Now is TDD really such a big deal?

Well yes I think it is. Uncle Bob says it best - "However, think about what would happen if you walked in a room full of people working this way. Pick any random person at any random time. A minute ago, all their code worked"

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

What an utopia :) Think if we could make that a thruth... Let's! Starting from now, Cornerstone will be delivering a couple of workshops with focus on delivering quality code. First out will be on O/R mapping, then we're going to follow up with TDD, Refactoring, Patterns ASF. Our mission is to make Swedish (and European) developers the most productive and effective developers in the world. Outsourcing? Bah, the developers in this part of the world will out run them all in competency.