What would be fun for fodder is to have a survey as to what rules people absolutely agreed with and which rules would be the hardest to accept if you joined his team (and please explain why on those).

I'm still wading through all the rules. Somebody's a bit too anal. Even though I find some of the rules a bit harsh, I've already sent links to my friends regarding stuff that I've been telling them for months.

My favorite rule so far came from "Rules to Better Websites." The Banana Rule Rocks. Also, the naming conventions are perfect. I've sent the list to all my buddies. Hopefully they'll get thier acts together.

I agree with Rob - it will take a while to sort through all the rules, but it's nice to know they're there. I especially like the rhetoric behind the rules (so that you make an argument either for or against it) because he's sharing his first-hand experience with it. The good news is that we can decide to accept it or reject it based upon our experience as well.

I also like the "best tools" section. You know Adam has been around the block a few times has weeded out a lot bad software and leaves us with his top choices - much like what Scott Hanselman does.

Hate to work for/with him. Can someone say code monkey ?

DNR-TV is the best!

Hey guys,

Adam's talk about rules was great... I found this cool little plug-in for VS6 called VBLaw. They have a vb6 and a vb.net version. I have only used the VB6 VBLaw application but it sounds at lot like the auditor Adam was talking about. I like it because it helps me identify sloppy code. Anyway, keep rocking! Jerry

I'm with Aaron as far as not wanting to work for him. I wouldn't go as far as code monkey.

One rule I definitely do not agree with is that striking through an item is a good UI practice. I just think that makes the screen look like garbage.

I also think that while the email bug tracking may work for him, I think it is rather clunky. I understand the argument about not wanting to copy emails, but if you only use your tracking system and not emails to report bugs it is a moot point.

Personally I found it mildly amusing, but not very informative.

Programming's Primary Technical Imperative: Reduce Complexity.

I think Adam's rules are great. I would love to be able to have a rulebook like this at work. I don't think it would be too limiting either, in fact I think the opposite. We make thousands of decisions when programming and if you can take away a number of mundane ones with rules, you'll actually be able to program higher quality code, and be more creative.

Great show!

Starting listening to the show, I thought this sounds nuts, thinking it would make development too restrictive in its process. But after a while I started to agree with the approach. In my experience, good code comes from good standards. So Thanks Adam, especially for putting these out to the community. I will certainly be checking them out in more detail.

I only just got Broadband so I've only just got round to listening to Adam's show ... this morning in fact.

God, I wish I had gotten the opportunity to work for / with Adam when I was learning VB3 through 6. I've worked with people that I've learnt a lot from but they never had a structure in place like this. Man, I would be a hell of a better programmer if they had.

I'm always keen to improve what I can offer my employers and customers, and this site is JUST the kind of thing that DotNetRocks should focus on more. The focus on particular areas of technology is great, but you should include a small section on best practices that the guest has developed over the years.

Fantastic show. I'll be listening to this one later tonight at home, making notes, and pouring through the rules myself to see which ones I can get adopted at work.

I simply love to work by Adams standards I always check the ssw website for his updated information it is very useful for me
Keep it up Adam