Thoughts on Technology, Methodology and Programming.

Misconceptions of Extreme Programming

Posted by Marcus Wyatt on 7 April 2006

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.


tags: , , , ,

Currently listening to: 1 – Winamp *** 124. Paul Oakenfold – New York disc 1


3 Responses to “Misconceptions of Extreme Programming”

  1. Ralf said

    I don´t think I´m missing the point off CCO completely. Pointing out having a low bus factor by following CCO, though, for me is not enough of a reason to follow CCO. I just value other aspects of software development higher. For example I value higher a clear separation between responsibilities thereby lowering the “cognitive load” on each developer. I value higher not spreading knowledge around that leads to high coupling. And I again point out: I don´t know of any other industry running projects like CCO suggests; but all the other industries don´t seem to suffer much from all those project team members getting hit by a bus 😉

    Also, of course I understand how TDD suggests (or even needs) decoupling using IoC frameworks and stubs etc. Great! And whoever follows my blog (or other writings) knows, I´m a great fan of IoC/Microkernels. But using a IoC and TDD is no substitution for planning ahead or an overall architecture. Using TDD to help finding the best contract for a component is great! But you better know your component beforehand. But where does the component come from? Who came up with the idead to have a certain component at all? There is only one answer, I´d say: someone who actually planned it and put it in a larger context with other components.


  2. maruis said

    I think your points have merit. But in my experience, I’ve found CCO to be more beneficial than creating silo’s of knowledge.

    On the other point of comparing Software Development with other industries, because of the fluid nature of software development I have learned that our engineering discipline can not copy practices from the other engineering fields. Because building a bridge or building is a much more static planning process. BDUF is possible on bridge projects, but as we know from statistics, it doesn’t work that well on software projects.

    We use TDD as follows in our SDLC:
    1. Iteration planning meeting – plan the stories, create some CRC cards, etc.
    2. When you select a story from the story board, you have a mini-design session (Unfortunately we don’t do pair-programming) consisting of two or more developers.
    3. Test-Drive the functionality
    4. Code review the design and code
    5. Integrate the code

  3. touch me said

    Thanks bud. Nice article you got going on here. Got some more sites to direct to which have a bit more info?

Leave a Reply


WordPress.com Logo


Twitter picture


Facebook photo


Google+ photo


Connecting to %s

%d bloggers like this: