The Champion, the Chief and the Manager

olvemaudal from Geektalk

Successful product development projects are often characterized by having an enthusiastic product champion with solid domain knowledge, a visible and proud chief engineer, and a clever and supportive project manager. And of course, the most important thing, a group of exceptional developers. From an organizational point of view it makes sense to require that all projects should clearly identify these three roles:

The Champion: The product champion is a person that dreams about the product, has a vision about how it can be used and can answer questions about what is important and what is less important. The product champion is required to have a deep and solid domain knowledge and will often play the role of a customer proxy in the project. This position can only be held by a person that is deeply devoted and has a true passion for the product to be created. The product champion is the main interface between the project and the customer/users. (Sometimes also known as: Product Manager, Project Owner, Customer Proxy…)

The Chief: The chief engineer is a technical expert that has a vision of the complete solution and is always ready to defend this vision. At any time, the chief engineer should be able, and willing to stand up to proudly describe the solution and explain how everything fits together. He/she should feel responsible for technological decisions that the exceptional developers do, but also make sure that the solution is supporting the business strategy. The chief engineer is the main communication channel between this project and other projects. (Sometimes also known as: System Architect, Tech Lead, Shusa, …)

The Manager: The project manager is a person that leads a team to success by managing the resources on a project in an effective and sensible way. He/she will be responsible for actively discovering and removing impediments. The project manager is the main interface between the project and corporate management. (Sometimes also known as: Scrum Master, Team Leader, …)

Of course, for very small projects these three roles can be fulfilled by one person, but for projects of some size there should be three people filling these three roles: one product champion, one chief engineer and one project manager. These three people must work together as a team, form an allround defence (aka kringvern) around the project, while being available to the developers at any time. Their task is to “protect” and “promote” the project to the outside world so that the exceptional developers can focus on doing the job.

I believe that identifying these three roles is the only thing an organization needs to impose in order to increase the chance of success. Then the team of exceptional developers together with their servants decide everything else, including which methodology and technology to use.

Visual Studio 2010 SP1 has been released

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

For those who are using Visual Studio 2010, the service pack has now been officially released: Visual Studio 2010 Service Pack 1 General Availability - Visual C++ Team Blog - Site Home - MSDN Blogs Edit: The download like doesn’t seem to work for me yet, given that it’s only gone General Availability today it might be worth checking back a little later. Edit again - we have a general availability download link: http://www.

If your VS2010 C++ build is constantly rebuilding a project that hasn’t changed

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

Check if you’re seeing the following output in the build pane: InitializeBuildStatus: Creating ".unsuccessfulbuild" because "AlwaysCreate" was specified. I’ve just fixed a bunch of these errors in one of our solutions here and all of these were caused by one of two issues: The project file referenced files that were no present in the source tree A custom build step either was supposed to generate a file but didn’t, or the file ended up in the wrong place In order to find out if there are missing files that trigger the perma-rebuild, you’ll also have to enable Visual Studio’s debug output as described in this stackoverflow answer.

How to view undecorated DLL-exported C++ symbols in Visual Studio 2010

The Lone C++ Coder's Blog from The Lone C++ Coder's Blog

Yes, it’s one of those “note to self” posts, but I keep forgetting how to do it. As the first step, you run dumpbin /EXPORTS and redirect the output into a file because the utility that unmangles the names (undname.exe) doesn’t appear to be able to take piped input via stdin. Then, run undname , with being the file that contains the exported symbols. At least that way the symbols become mostly readable.