>I'm kinda disappointed to have no notice or chance to defend a suggestion. Mine for a debugger category had all of maybe two hours time to be read. Now I find out that today's conference decided the matter. I'm calling FOUL. AFAIC, the suggestion still stands.

Nancy,

While I was at the conference yesterday, I didn't get there until late and don't know if there was any kind of vote on your suggestion. It may have been discussed (which is fine, as far as I'm concerned), but whether or not it was put to any sort of "vote", I don't know (and as Mike stated, didn't occur).

I'd first like to say that I think it's a fine suggestion. I wonder, however, if there's a way to include the coverage profiler in the description. While it may not technically fall into the category of "debugging", it is used to uncover "problems" within an application.

While voting on an issue is nice, it's hardly always the best way to do things. Sometimes, it's the worst. Let me share a couple of personal experiences in this area that I think can be applied here.

The company I work for is the largest manufacturer of carpet in the world. The division I'm in, contract carpet (the stuff in offices, restaurants, hotels, etc.), is also the largest in the world and the best.

The division manager of manufacturing once gave me this instruction, "Delight your customers". What he meant, naturally, was my users.

I've written more than a dozen applications which track how efficiently an individual process in manufacturing is being done. These are installed in 4 manufacturing plants in Cartersville, and others in United States and around the world. Quite often I get requests for modifications to these systems. One of the most requested modifications involves changes to the system so that the plant management can track how efficiently the personnel is doing their jobs. These requests are always rejected.

Why is this given the instruction to delight my customers? The systems were designed (by myself and the manager) to be product, not personnel management tools. To grant these requests would fundamentally change the underlying purpose of both the system and the reports they generate.

This is not the only reason these requests are rejected. All carpet is not alike. Some products are significantly more difficult to produce, and accordingly, are often delegated to the most skilled employees. The converse is also true. Due to this, using the information generated by these systems could quite possibly cause management to make erroneous decisions regarding the capabilities of the employees in their charge. For these reasons, this type of request is always rejected, despite the fact, that if it were put to a vote, everyone would want them.

There's another type of request that's always rejected: implementation of modifications that create a plant specific solution. The modification must be one that can be utilized by all plants using the system or it isn't implemented. It's obvious, given the need for maintenance and support, why this is the case.