Chris Menegay's WebLog - All Comments

re: Q&A from the Redmond Ascend Team System Training

Daddy93 — Thu, 22 Oct 2009 22:57:03 GMT

Note Do not configure a trust anchor for a signed zone on the server that is authoritative for the same zone. ,

re: Team System Q&A

Boy33 — Thu, 22 Oct 2009 22:57:00 GMT

In person he is sober and humane, but in his posts he likes to provoke. ,

re: Am I off my rocker?

AngryJay — Sun, 21 Dec 2008 18:40:10 GMT

if you are a rocker you must see this: (heavy mashpits)

nz.youtube.com/watch

Effects of snorting buspar.

Buspar. — Thu, 06 Nov 2008 07:55:51 GMT

Dose of buspar in dogs.

Started running VS Team Suite NOT in a VPC

Started running VS Team Suite NOT in a VPC — Mon, 26 Nov 2007 11:34:27 GMT

Pingback from Started running VS Team Suite NOT in a VPC

re: Answers to some VSTS Questions

Benjie Fallar — Tue, 11 Sep 2007 06:27:55 GMT

Hi,

I would like to inquire if you know a document or guide in asking our customer about their plan in using VSTS/TFS for their SDLC. I'm particularly interested a set of questionnaires in planning the usage of VSTS for a customer, such as templates or any tool.

Thanks.

One of the Wolves » Blog Archive » Are we speaking the same language?

One of the Wolves » Blog Archive » Are we speaking the same language? — Mon, 26 Jun 2006 20:32:49 GMT

PingBack from http://www.oneofthewolves.com/2006/06/22/the-practice-broadly-questioned/

Build trust not process.

TSHAK — Mon, 01 Aug 2005 23:01:00 GMT

I agree that we need to hold developers accountable for changes in the code. I also agree that tighter control is required after "code complete". However, for the most part, requiring a work item for every checkin will prove to be a disaster for productivity. Developers are the designers of the software, and they must design within the customers requirements. They must also be free to explore that design, without the burdon of a heavy process. They must also be trusted to work within those requirements. This is why we have small iterations in which the customer (or PM, PdM, or other stakeholders) can review a working build to help ensure that the developers are meeting (or going outside of) the requirements. This is why we have good dev leads that we also trust to keep a good eye on all checkins that are being made.

I don't have any problem with processes like checkin policies and the like. However I agree with Jeff's point on using VSTS to control what developers work. I too think it will affect developer retention, at least of the smart and creative kind.

re: Q&A from the public training class

Carl Daniel — Thu, 28 Jul 2005 00:31:00 GMT

You can do unit testing on C++ code with a bit of work. You have to create all the tests by had (no "Create Tests" in the editor context menu), and you have to use a C++/CLI unit test project that uses interop to exercise native C++ functionality.

Coverage from unit tests should still work, including coverage of native code, assuming you add all the appropriate executables to the list of modules to be instrumented.

re: Am I off my rocker?

Jeremy Miller — Mon, 18 Jul 2005 19:22:00 GMT

Chris,

First off, I did think the talk was very good and I thought you were clear, I just disagree with the one particular statement. I don't think VSTS brings much to the table for me in specific, but I'm not in a typical situation.

I think I misinterpreted your remarks somewhat, but my point is really that developers *should* be both knowledgeable about the process and have some responsibility for the process. Who in the world knows more about software development than software developers? Much of the inefficiency in software development happens at the boundaries between requirements, coding, and testing. People need things from me and I need things from them. I'll be a better developer if I understand what's going on around me and actively contribute to process optimization. If VSTS helps with that then that's a cool thing. Besides, I can just hear someone on the VSTS team in Redmond saying "Mort doesn't care about process" and that kinda thing always annoys me.

The reason I still think VSTS is targeted at large companies is that they're the folks that have severe transparency and communications issues. Some of the features (especially the policy enforcement stuff) would have been a godsend to me when I worked at a Fortune 100 shop. Being a small shop, our project transparency is already very good. Just using a simple Scrum process for iteration/release management and the daily burndown chart provides every member of my team plus management with visibility into what's going on with not much more sophistication than Excel and a Wiki.

When I said "laborious" I should have said "high ceremony."

Thanks for all the extra blog traffic btw;-)