CodePlex Development Process

CodePlex Development Process

  • Comments 1

One of the things I would like to do with my posts here is to give people a bit of an inside view as to how the CodePlex team does what it does. I'd like to start with a brief overview of how our development process works.

For those of you who don't know Jim Newkirk, he was one the original authors on the NUnit project. NUnit (and the whole xUnit family) are probably the best known unit testing frameworks available for developers. Since Jim runs the CodePlex team, it's probably no surprise, then, that some of his personal style affects the way we do development.

On the team, our process is very similar to eXtreme Programming (despite Microsoft's current infatuation with Scrum, we are still doing an XP-style planning game). The team has been running one week iterations for more than a year, with our PM George now leading both the iteration planning and stand-up meetings. Now that we have launched the site, we plan for frequent releases of the software (our plans right now are roughly every three weeks, to ensure that we have given each release adequate regression testing and stabilization time).

The CodePlex team are strong believers in customer-centric development. We encourage our users to submit feedback on the CodePlex application, and offer them three ways to do that:

  • Use the CodePlex forums to post a message when something requires or invites discussion in the community.
  • Submit bugs and feature requests using the CodePlex issue tracker.
  • Use the Contact Us page if you need to talk to us directly about a support or other sensitive issue.

Our iteration planning and release planning is heavily influenced by the issues reported by the community. As we perform each release, we make note of it in our Wiki, including links to resolved customer-reported issues and feature requests.

Software development style is also very reminiscent of XP. We frequently pair program, and all production code is written test-first. There is no strong code ownership: everybody is free to change any code in the pursuit of whatever task they happen to be working on. This is probably no surprise, since all the developers on the team are agile enthusiasts (and sometimes evangelists).

Most importantly, we all work together in a single shared space. We don't have private offices, instead choosing to sit together in a team room for improved communication and teamwork. It's not quite a nice as my old space, but we're working on it... :)

- Brad

Leave a Comment
  • Please add 4 and 1 and type the answer here:
  • Post
  • One of the questions I got asked in the interviews I discuss below was whether we used agile methods...
Page 1 of 1 (1 items)