This project is read-only.

Project Roles and Kick Off meeting

Nov 30, 2007 at 7:39 PM
Edited Nov 30, 2007 at 7:39 PM
Guys - I'd like to suggest that we define some project roles so that we can make decisions more effectively. I'm using the terminology we use here at Microsoft on product teams but I think that it makes sense


  • Program Manager - responsible for planning releases and overall coordination of the project
  • Architect - responsible for system design
  • Dev Lead - responsible for coding standards, check-in policies, project structure etc.
  • Test Lead - responsible for test strategy, test plans, sign-off on builds before they are promoted to releases

Because the group of contributors is much larger now I'm suggesting we need this level of coordination put in place and soon. The roles don't mean that you can't do other things as well. For example if you are the test lead you can contribute ideas to the architecture and you can write code as well. It just means that we look to you to coordinate the efforts and strategy around that role.

Team Communications

We need to have a regular meeting of the project leads (probably monthly or perhaps bi-weekly initially). We can use LiveMeeting to do this we just need to pick a time that works for every one

Email Group

I have created an MSN group for email and scheduling of meetings at You can visit the site at

Project Meeting

I would like to suggest that we have a meeting very soon (sometime in the next week). Since we have team members in Sweden and others in the US I would suggest a meeting at Thursday December 6, 2007 at 7:00am Pacific Time (GMT-8 where I am near Redmond) which would be 1600 in Stockholm (GMT+1). This schedule works pretty well unless we have some folks in Asia.

The topics for the first meeting would be
  • Who is in what role
  • Review of the proposed architecture for Doppler 4
  • Others as suggested by the team (in advance)


  1. Please let me know if this meeting time works for you or not. If it does not work, please suggest 2 or 3 alternatives.
  2. If you would like to serve in one of the project roles, please let us know which one and what experience you have for this role

Nov 30, 2007 at 8:14 PM
I'd like to volunteer for the Architect role. I have been practicing architecture for the last 7 years and host the show ARCast.TV where I speak to architects around the world. Hopefully I can bring a good design perspective to the project.

I welcome the input of others on the design as well, after all this is a colaborative effort. However in the end you need someone to be responsible to drive such decisions.
Dec 2, 2007 at 8:55 PM

Great proposal. Indeed, to me you seem to be a great person to hold the architect role. You bring in a lot of experience, which I very much welcome. I would like to step up as the program manager (I guess makes sense, as I'm the one who started this whole thing anyway ;-))

Regarding the proposed time: that is unfortunately not working for me. I mainly spend my working days at customer sites, which also mean that I cannot spend time doing private tasks. 2 hours later (1800 Stockholm time) would be much better for me. Thursday in itself is a perfect day for me though.

Dec 3, 2007 at 9:35 AM
The original time Ron suggested is 3pm here.

The time suggested by Erwin is good for me. Our company office is a single room/floor with 4 desks in it, which means there is no privacy for doing a live meeting. At 17:00 GMT I will be able to have a live meeting without any problems.

Any later than a 18:00GMT start will not work for me this week as I have no internet at home right now. Once the connection is activated, sometime in the next 3 weeks, then I will be able to do project meetings almost anytime outside of office hours.

Dec 3, 2007 at 3:09 PM
Ok then - let's set the meeting for Thursday December 6, 2007 at 9:00am (GMT-8)
Dec 5, 2007 at 3:06 PM
I have some things that I would like to discuss during the meeting. Possibly we should make these into discussions on here as well.

TDD vs BDD - As this seems to be a learning experience for all involved I was thinking we could take the opportunity to look into the BDD style of development.

CI tools - I think that CruiseControl is the favourite out there and with Camalot working on CCNetConfig we will have some expert advice. We need to confirm that this is what we are doing and work out the best way to have a CI build running. Will we be using NAnt to perform the tasks or is MSBuild up to the job? I have only ever used NAnt for doing builds as most of the things that I have automated were written in 1.1.

Inversion of Control and Dependency Injection - If we are going to go ahead and use the MVP (specifically presenter first) is it worth looking at using Inversion of Control and Dependency Injection to help with the testing. If we do use these techniques is it worth looking at ObjectBuilder (which I think that Ron is familiar with)/Structure Map/Windsor etc, or is that going to be overkill for a desktop application of this size?

Installer - Will we be looking at using WiX as the installer technology? I have found this to be very useful in the past, however I have never used it for pretty installers with UI on them.

User Stories - I have become used to working with User Stories in the Scrum/XP sense of things. Are we thinking of working this way? I was thinking that we might make posts that have the high level user stories in them. We would then need to break the user story down into tasks. Can this be done within the TFS model, is there a hierarchy of work items? Or do we just make the high level posts and then break them down into tasks and make the task posts into work items? Or is there a different way to work with the TFS supplied by CodePlex?

Sorry for all the questions. My head is all jumbled up with everything that is going on here and in work :)
Dec 5, 2007 at 3:29 PM
I think MSBuild will be just fine. I use msbuild in all my projects, while i'm not saying i am an MSBuild expert, i do know my way around using MSBuild.

I, myself like WiX, i have used with some minor UI but nothing really customized, in past projects. Building it is easy with msbuild as well.
Dec 5, 2007 at 5:43 PM
With regard to complexity and new ground keep in mind that every time we choose to do something that we know little about we introduce a great deal of risk into the project. That does not mean we shouldn't do it, it just means that we ought to have a good reason and a high degree of confidence that we can succeed in doing so.

A number of issues have been raised thus far so here are my thoughts on them.


I once did an ARCast with Claudio Perone in Dublin on BDD. I like the concept but I'm not sure I understand it well enough to execute on it. We should investigate - I found as a resource.


My vote is to go with the simplest thing that will possibly work. VS Setup Projects generally work and are pretty simple. I have not used WiX but my guess is that it would be more difficult.

User Stories

Yes we should do user stories as a basis for driving the project. We should add these as Tasks prefixed with User Story: For example User Story: Subscribe to Podcast. User stories naturally get broken down into a set of tasks or smaller user stories. We should come up with a list of initial user stories we intend to use for our first iteration. If User Story "A" means that tasks "A, B and C" must be complete I suppose we can enter these as work items. On the other hand we could just say that the User Story is the work item and just do the work it takes to implement the user story.
By the way... though I have spoken with a lot of agile people and read many agile things, I have never participated in an agile project so feel free to help me learn this process if I'm getting it wrong.

Implementation and UX design

I'm going to suggest that we work from the inside out to produce the podcast engine first. Getting the engine right and driving it from XML config or programmatically with tests would be a good initial goal. Then later we can attach a UI.

I'm looking for a good UX designer who will work with the project on the UI. We have a number of UX evangelists at Microsoft who might be willing. For this reason I want to delay the UX design until we have a designer on board.
Dec 5, 2007 at 7:49 PM

Live Meeting Details for the Kick Off Project Meeting

Date / Time: Thursday December 6, 2007 9:00am Pacific Time (GMT-8)

Hello Everybody – if this is your first time working with LiveMeeting I would suggest that you take some time prior to your first meeting to install the Live Meeting client and get everything setup and working fine.

I will have some slides and we will be able to share information over text and voice. You might want to be sure that you have a headset you can plug into your PC setup and configured prior to the meeting as well.

If you are having trouble with the Hyperlink to Join the meeting (I noticed that Hotmail didn’t work with this link). You can start Live Meeting from the start menu and then enter the conference information from below.


Ron Jacobs has invited you to attend an online meeting using Microsoft® Office Communications Server.
Join the meeting.;gruu;opaque=app:conf:focus:id:dee335c87e7c4e9cb28e7243dc49a55d%3Fconf-key=07fUBI3fVIk

Audio Information

Computer Audio
To use computer audio, you need speakers and a microphone, or a headset.

First-Time Users

Make sure the Office Live Meeting client is installed before the meeting:
• I am connecting from outside the Corporation network


Unable to join the meeting? Launch the Office Live Meeting client and join the meeting with the following information:
Meeting ID: dee335c87e7c4e9cb28e7243dc49a55d
Entry Code: 07fUBI3fVIk

If you still cannot enter the meeting, contact support:

• Outside the Corporation network


Office Live Meeting can be used to record meetings. By participating in this meeting, you agree that your communications may be monitored or recorded at any time during the meeting.
Dec 6, 2007 at 3:27 AM
I can do the WiX setup if we want to go that route. I dont claim to be a master at it but i know how to do the basics and some of the advanced stuff with it too. Like creating shortcuts, using UI to ask the user where to install, adding a EULA screen etc.
Dec 6, 2007 at 9:50 AM

camalot wrote:
I can do the WiX setup if we want to go that route. I dont claim to be a master at it but i know how to do the basics and some of the advanced stuff with it too. Like creating shortcuts, using UI to ask the user where to install, adding a EULA screen etc.

What would be the reason to pick WiX over the build in Setup Projects in VS2008? I use those all the time and they work perfectly for me actually. It feels to me that we will only make it a bit more complex if we're going to use WiX, but maybe I'm missing something.
Dec 6, 2007 at 10:50 AM

dopplerradio wrote:

What would be the reason to pick WiX over the build in Setup Projects in VS2008? I use those all the time and they work perfectly for me actually. It feels to me that we will only make it a bit more complex if we're going to use WiX, but maybe I'm missing something.

The reason that I have used WiX in the past was that I could not find an easy way to create the MSI from a setup project without a reference to DevEnv. This might have been something that I overlooked, but I wanted to have build machine that did not have VS on it.

The other thing that it let me do was poke the XML during builds from within NAnt. So version numbers and product codes etc were updated on successful test runs, MSIs were created and copied to our deployment box.

It also gave me greater control over the MSI. Before writing the installer in WiX I had written a utility to query the internal MSI database and tweak values in there as part of the automated build (this was when we were using VS to create the MSIs). There were certain settings that VS2003 defaulted to that we did not want and needed to change for our unattended installs. All of our software was installed to 300+ sites (not in an AD) using CA Software Delivery.

If VS 2008 and/or MSBuild lets us run a CI server without VS installed and can produce MSIs then I am happy to work with that to start with. Until we have a need for greater control. WiX supplies a utility to be able to reverse engineer an MSI into a WiX build script, so switching is still an option later on.
Dec 6, 2007 at 9:56 PM
Aiden brings up a good point that I forgot about. Using WiX allows us to pass version or other info that may not be know until the build is successful. Now if the VS Setup can do all this, and be automated as well by CI, then it really doesn't matter. I have more knowledge of WiX then the VS Setup project.