Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

eXtreme .NET: Practice Your XP with a Fictional Case Study

Here's a perfect chance to be the proverbial 'fly on the wall' as you listen in on a team's efforts to use XP (eXtreme Programming) techniques to improve the way they deliver software.


advertisement
n my book, "eXtreme .NET," I introduce a team of developers who are learning how to improve their ability to deliver great software. In this article, you'll follow this team as they learn about a new tool to help them develop software solutions using the .NET Framework. The tool they are going to explore is called Cruise Control and it helps the team continuously integrate their code. The greater the time between integrations the larger the issues will become. Performing frequent code integration minimizes the risk of the issues getting out of control. CruiseControl.NET is a great tool to automate the reduction of risk by ensuring that any code that is checked-in to the source control is integrated.

This team consists of the following members:

  • eXtreme Eddie: Eddie has been programming for more than 20 years. He has done everything from mainframe work through embedded systems. Eddie was an early adopter of XP techniques and has been using XP in Java projects for the past couple of years. Eddie embodies the XP spirit.
  • .NET Deepak: Deepak is a young, smart coder. He graduated last year but has been using the .NET Framework since it first went into beta. Deepak knows and loves .NET. Deepak represents all there is to love about .NET.
  • Skeptic Sue: Sue has been in software development for 10 years. She has mainly developed Windows software in C and C++. Sue was promoted in her previous job to project manager, which she hated. She left and joined this team so that she could get back into developing software. Sue carries the scars from many failed projects and doesn't trust new ideas.
  • Panic Pete: Pete is very bright and comes up with amazing solutions for problems. He is the clown of the team. Pete has been writing code for 5 years but has never finished a single project he started. Pete panics when the going gets tough and verbalizes this panic. When this happened previously, he quit.
  • Customer Chris: Chris is the internal customer for the team. He works with marketing and the customer support team. Chris once tried to write some code for a training course. He didn't enjoy it. Chris is a people person: he loves engaging in conversation.
Set up a tool called Cruise Control to do automated builds and provide feedback about the state of the build.
The team has been not been together for long but they have learned a few things about XP from Eddie. When Eddie first arrived he insisted on removing the cube walls to allow the whole team to sit in an open plan space. Each developer has their own desk, but often you'll find only half of those desks being used. The team has adapted quickly to use a technique called pair programming. When they are pair programming (or pairing), two developers will sit at one desk and work together on a single piece of code. This allows the team to learn from each other more than they ever did before. The open plan space helps them to work much more closely as a team. One of the benefits of team programming is that conversations can be overheard and help more readily given to resolve issues.

Imagine yourself, CoDe Magazine reader, as a fly on the wall of the workplace. From this perspective, you can see how the team works together and learn the lessons they are learning. You might also spot some things they are doing wrong or that you would do differently. Your task as the reader is to think about what things you would do the same or differently if you were on the team; maybe the team can change the way it is working and improve. Don't hold back—anything goes here. I want you to tell me your opinions and I'll use them in the next installment of this series. (There is an advantage to a publication that gets published every other month.) If you think that a team member should be fired, let me know. If you think they need to hire new people, let me know. If you think they should cancel the project, let me know! Send your ideas to ideas@extreme.NET.Roodyn.com. The best idea (in my opinion) will win a one-year subscription, or an extension to your subscription, to CoDe Magazine.



This team will also learn to use new tools through the course of their project. From your position as an observer, you will be in an excellent position to see how the tools might suit your own needs. Let's join the team now as they meet to discuss their new project.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date