Spawned by some pet peeves with other .Net developers over the years, let me know which of these you agree with and which you don't:

1) Thou shalt not make solutions for programs that contain 30+ projects for single pieces of software (ie, for one website, for one program).

No matter how clean you may think the "architecture" is, its not. The compiler can't do its job optimizing when you have 30+ dlls separating methods with 5 lines of code in them. If you look at your program in a profiler, 80% of the operations it'll be doing is jumping around the stack trying to hit all the methods.

2) Thou shalt carefully use XML.

This is spawned by seeing someone send all multi-ID select statements to SQL using XML, having SQL parse that XML and then do a select on it. Come on, XML is awesome but why are you adding the overhead when you could just use a delimited string? Similiarly, if you're going to serialize your stuff, create the serialization assemblies at compile time and don't make the XML "stupid" (IE, nesting dozens of elements when you could be using attributes).

3) Thou shalt not write your own ORM.

Holy crap. Talk about reinventing the wheel. I don't care how slick you think your reflection based ORM tool is and how great an architecture you feel it has - as soon as you start to scale out you'll notice huge performance problems when you're querying the crap out of the database. I dig that bleeding relational logic into applications has a tainted feeling to it but performance is king.

4) Thou shalt not abuse singletons. Thou shalt properly handle memory.

I put these two together since usually major memory problems stem from singletons referencing "orphaned" objects. Singletons are nice, we do not need singletons to handle every aspect of the program however. Dispose of objects you don't need when you're done with them.

5) Thou shalt page-heap validate any program that uses COM or unmanaged code.

.Net unmanaged interop and COM interop work pretty well, but when you need to use it for goodness sakes run it with page heap on at least once or twice. Many months of debugging have been lost to random heap corruption from third party libraries that could've been found early in the cycle and isolated in a background service.

6) Thou shalt make simple libraries for cross-cutting concerns, these libraries shall be able to be disabled and thou shalt not create interdependencies from cross-cutting concerns.

I can't tell you how many times I try to rip a single library out to validate its memory only to find out it references a configuration library to do something stupid like get its default log file and require to be chained to 15 other libraries just to handle logging and configuration settings. There's seriously nothing wrong with passing parameters like that in the constructor rather than referencing some configuration singleton all over the place.

7) Thou shalt not be use ridiculous amounts of GDI objects.

For Windows application development, for goodness sakes, minimize your usage of controls. Its embarassing to see a simple report generation software use 90mb of RAM to display its stupid form. In general, keep an eye out for how much memory you're using when you use Windows forms, because on the average those controls take up far more memory than they should.

8) Thou shalt not use multithreading/timers unless thou doth understand the concept of synchronization objects.

This one is somewhat self-explanatory. I can't express how often I've seen people wrap non-threadsafe code into background timers to free up the UI only to have it randomly trash the app.

9) Thou shalt not make 150 SQL tables when you can make 15.

I know having 30 columns isn't pretty but again, performance is king. If you can avoid doing 30 joins to create your objects its probably better that way.

10) Thou shalt consider performance in your choice of web controls.

Ugh, for god sakes people, if the most popular pages on your site are handled at 4 requests per second you're doing something wrong. Typically what I'll do here is create the page with the control, view its HTML output, then create a control that generates something similiar to that but fitting whatever data I need to. The net result is a "stripped" down version of the control with the same functionality but 50x the performance. In general though, making AJAX sortable grids all over the damned place isn't going to woo users when it takes them 15 seconds to load your page.