exceptionz

Thoughts on Technology, Methodology and Programming.

Archive for April, 2006

Extreme Programming in Practice

Posted by Marcus Wyatt on 14 April 2006

Jefferey Palermo has the following posts about how Extreme Programming helped his team to successfully deliver their software system to their client. He highlights not only the good that he experienced, but also speaks about the bad and ugly:

I’d recommend these posts. The posts are really informative!

 

tags: , , , , ,

Posted in Agile, Refactoring, TDD, XP | 1 Comment »

Return on Investment for Agile Practices

Posted by Marcus Wyatt on 12 April 2006

Wow, ThoughtWorks, an IT consulting company heavily involved with the agile movement has commissioned Forrester Research to perform an assessment of their processes; here you can read about their results. Look at the following example Results:

  • Improved time to benefit by 69%
  • Reduced cost by 57%
  • Reduced effort by 62%
  • Reduced critical defects by nearly 80%
  • Reduced overall defects by more than 60%

Now who can not seriously consider implementing Agile practices with results like above.

tags:

Posted in Agile | Leave a Comment »

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

Posted in Development, TDD, XP | 3 Comments »

 
Follow

Get every new post delivered to your Inbox.