Tales from a Trading Desk

Noise from an Investment Bank

TechEd from a Java Perspective

I noticed a few bloggers including Brad picked up Norman Alex Rupp recent TechEd blog postings. "These people don't write code--they have forms and wizards for developing just about anything you can think of. When they do write code, they have development tools that actually force them to write unit and performance tests" is an interesting statement from Norman.  Over the last x months we have been churning through a lot of .NET candidates, a large majority of them really don't seem to care what code wizards generate, how .NET works under the covers, or why certain things work the way they do.  A majority of the .NET candidates we've seen also don't seem to care or understand about performance issues. That's why the FxCop/Unit testing/etc integration that Microsoft is adding to Visual Studio 2005 is the best thing to happen to VS for a long time.  At least now, developers who stay in the IDE world, can run everything in their world, and not have to think about running tools like FxCop externally - and hence not bothering to do so.  I for one think that FxCop should be enabled by default in all VS projects - when I check VS 2005 May CTP last night, it appeared to be disabled by default.

Posted: May 28 2004, 12:29 PM by mdavey | with 7 comment(s)
Filed under:

Comments

Robert Hurlbut said:

+1 for FxCop on by default. Excellent comments about how developers are getting away from understanding the internals and the best ways to write correct .Net code. Hopefully, with some of the tool improvements, many developers will get a push in the right direction.
# May 28, 2004 7:42 AM

Scott Galloway said:

Hmm, I'm not for FXCOP on by default - how I write my code is up to me - not standards defined by a tool. If I choose to follow FXCOP standards then fair enough, I can switch it on.
# May 28, 2004 8:00 AM

Robert Hurlbut said:

Fair enough, and that makes sense that you may want to follow some standards that are specific to your organization. What I like about FxCop, though, is that it finds things you may have missed, or would like to know more about how (like security errors in the code). Plus, FxCop can be updated to your particular rules. With the tool's help or not, it is always a good thing to check consistency in the code against whatever standards you have adopted.
# May 28, 2004 8:13 AM

Peter Ibbotson said:

I'd give +1 for FxCop on by default, but I don't want people to start ignoring the messages, for example some of the rulesets are irrelevant to a large set of developers (Globalisation and perhaps the NamingRules) so would they end up ignoring not just those ones but also the security ones?

Matt, I've been getting crappy download rates for the May CTP (typically 10-20KB/Sec over 2Mb ADSL line and it's still not finished) what did you get? 'cos I may try the download at home over the cable modem at this rate and complain at $Works ISP.
# May 28, 2004 8:17 AM

Matt said:

Yeh, I was getting crap rates as well, took about 24 hours to come down over my broadband connection
# May 28, 2004 8:21 AM

ksuh said:

Hmm, I've seen lots and lots of poorly performing Java apps/web sites. I guess they all suffer from the same problems as well then.

It's the programmer(s), not the tool.
# May 28, 2004 12:47 PM

P Schuh said:

I'd love to see FXCOP on by default, it should be no big deal to turn off, but that extra effort would, hopefuly, result in more developers using it. The quote was not NAR, it was attributed by him to Steve Ballmer, which makes it all the more interesting, IMO.
# May 30, 2004 9:07 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)