This post originated from an RSS feed registered with .NET Buzz by Maruis Marais. Original Post: Misconceptions of Extreme Programming Feed Title: exceptionz Feed URL: http://feeds.feedburner.com/Exceptionz Feed Description: I am an XP, TDD, OO and .NET enthusiast. Things like Design Patterns makes my pulse race, I love learning exciting new things and to share my thoughts and techniques with the world. So join me and together we can explore the awesome world of software development Latest .NET Buzz Posts Latest .NET Buzz Posts by Maruis Marais Latest Posts From exceptionz

Ralf's Sudelbücher had a post about Collective code ownership is limiting software quality where he is saying that CCO is just a coping technique.

I think that he is missing the point of CCO completely. He is mainly talking about technology. Probably every professional developer out there today will tell you that it is impossible to be an expert in every conceivable area of software. The field of software development is too big and wide for any one developer to have an expert understanding of the whole discipline. I personally believe you should have a good base to work from (Good OO understanding) and a general understanding of technologies available. Now, at the same time the team should spread the technology research between them.

In our company, we might have four or five projects running at the same time. We have SQL experts, but they also have general programming capabilities. Thus giving our team the ability the share the unique knowledge between project teams as needed and at the same time spreading the SQL knowledge through pairing with non-SQL experts when implementing specific SQL functionality. Thus, the project does not have a bus factor at any point. We have a concept of assigning specific technologies the company thinks it needs to invest in, to technology groups. These might be three or four individuals in a group to research and become experts in a specific technology.

On another point he makes, when using TDD to drive your implementation and code, at some point if you have done it incorrectly, the code will hurt you. Why? Because you will have HIGH coupling between your object and you will start to feel the pain of fragile, breaking test. So what does this mean? Developers today still write procedural code. Go look at some of your code that you’ve written maybe yesterday, run a metrics tool like SourceMonitor over it, and if you find any code above 10 in Cyclomatic Complexity, I can guarantee you’ve written procedural code that is breaking some sort of OO rule. (Single Responsibility, Open Close, etc). I've written a code project article on exactly this type of code and how easy it is to write code with high complexity.

The way TDD forces you to write loosely coupled code is through having to replace external dependencies in the class under test with Stubs or Mocks using Inversion of Control and Dependency injection. Moreover, because Mock frameworks normally can only mock interfaces, this will force you to communicate to the external component through an interface, which means you have low coupling between these two components. Knowing Design Patterns will also help you to practice TDD more efficient.

On another note, I think he is also missing the relationship between the XP practices and the roles these practices play in supporting each other. If you look at CCO in isolation, you are missing crucial benefits you are getting when you look at CCO in context to the other practices. What do I mean? Well, all the practices of XP support each other and as a whole make developing software easier and more productive, reducing the risk of failure. Have a look at this essay explaining this in more detail.