Have I inherited a disaster?

I hate taking over someone’s bad code. The projects always go on forever and you are forced to follow bad practices to try and string together fixes and features without it all crumbling down. There are some quick, not always 100% accurate, ways to know whether you’ve inherited a disaster. I’m strictly talking about enterprise scale projects here, some of these practices might be ok for smaller stuff. Some of these are hard to quantify (what’s too much?), it’s all very relative to the size and type of your project.

(if you are interested in a more detailed analysis, I’d recommend NDepend and FxCop. I actually recommend FxCop for your day to day programming, it’s a wonderful tool. Both are free)

Hit ctrl-shift-f from the 2nd dropdown box, select to look in the “Entire Solution” and enter the following into the first box:

1 – ‘catch’
The results that get displayed will give you a good idea about what type of exception handling you’ll have to deal with. If there are many lines with just “catch”,  “catch(Exception XYZ)”  or “catch(XYZ)” you’ve got some bad exception swallowing happening. You should expect to see this no more than once or twice (in a global handler). If you are seeing specific exceptions being caught, all’s good.

2 – ‘throw;’ and ‘throw e’
If “throw;” returns a lot of hits, I’d say it’s a good sign – the previous developer understood not to mess with the stack trace when rethrowing exceptions (you should spend a bit of time figuring out what he/she was doing catching the exception in the first place). “throw e” implies that exceptions are being caught and poorly rethrown.  I use “throw e” because most people will name their caught exception “e” or “ex”.

3 – ‘throw new’
Unless there are a lot, this is a good sign. The developer wasn’t afraid of throwing exceptions. A good way to tell if he or she might have been over zealous is to see if these are spread out amongst many classes. In my experience, throwing exceptions tends to be centralized in like-classes.

4 – ‘: Exception’ or ‘:Exception’ (VB.NET ‘Inherits Exception’) (also try ApplicationException)
It’s hard for me to imagine large projects without at least some custom exceptions.

5 – ‘using (‘ and ‘using(‘ or ‘finally’
Developers who can’t cleanup their resources aren’t likely to cleanup their code – sorry. Hope for a lot of these!

6 – ‘on error resume next’  (VB.NET only)

(FxCop does a lot of analysis around exception usage, so I’m going to recommend that you use it again.  You can learn more about exception handling here.)

5 – ‘StringBuilder'”
Few applications get away without needing to do a good amount of string concatenation. There’ve been so many blog posts about the importance of the StringBuilder class, that if you don’t find any it not only means you likely have ugly string concatenation and performance issues, but the developer didn’t spend much time learning and reading.

6 – ‘.Fomrmat’ and ‘.AppendFormat’
I’ve expressed how important I feel string formatting is in the past, so no one should be surprised to see it in this list. Have fun maintaining impossible to read code if you aren’t seeing many of these. (if the line looks like an SQL string, then take a quick skip to #9)

7 – ‘.ToString(“‘
Somewhat related to the above item, .NET has great built-in functionality to help you format all types of data (dates, numbers, etc) into meaningful string. You’ll likely find a lot of ToString()’s in your code, but you should also find a healthy number of ToString(“XYZ”)’s

Data Access
8 – ‘SELECT ‘ or ‘UDPATE ‘ or ‘DELETE ‘ or ‘INSERT ‘
In my experience, people who use inline SQL statements simply haven’t bothered to learn how to use stored procedures. Now you get to pay the price for their laziness.

9 – ‘+ ” AND’  (VB.NET should also do ‘& ” AND’)
Inline SQL statements aren’t the end of the world, but injecting parameters via string concatenation is horrible (even if done via a string.Format). There’s a good chance the code has security holes, sorry.

10 – ‘new DataSet’
While not everyone will agree with me that DataSets shouldn’t be the foundation of an enterprise scale project, it’s good to know that you’ll be dealing with them.

11 – ‘”<‘ (change the file type to *.vb;*.cs)
You’ve possibly just found HTML or XML manually being put together. Who needs ASP.NET or System.XML, not your predecessor!

12 – ‘Response.Write’
See above

13 – ‘HttpContext.Items’
The HttpContext is a new introduction to ASP.NET and it’s quite powerful. Unfortunately it’s also quite underused. Seeing the variables stored and retrieved from the HttpContext.Items collection is an good sign

14 – ‘OutputCache’ and  ‘Cache.Insert’
Despite the fact that server side programming exists to deliver dynamic content, there’s almost always something that can and should be cached. You’ll often see programmers coming from another language overlook this because it’s not something you’ll find in many frameworks.

15 – ‘configSection’ ‘httpModules’ ‘httpHandlers’ (in the web.config)
Seeing custom configuration, use of HttpHandlers and HttpModules should be a very encouraging sign. It’s a decent sign that the previous developer had a solid grasp of ASP.NET. I wouldn’t panic if I didn’t see these though.

16 – ‘SqlDataSource’
While there might be some debate about the properness of DataSets in enterprise-type application, hopefully we can all agree that you shouldn’t find any SqlDataSources in your code.

17 – ‘interface’
If you don’t find any interfaces in your project, you could be in trouble – especially if there are a lot of classes.

18 – ‘(I’ (dunno about VB.NET)
I’m not sure what it means if you find a lot of interfaces (above), but not much code that’s casting to them. I think I’d be happier a few hits on both.

19 – ‘abstract’  (VB.NET ‘MustInherit’)
Somewhat similar to interfaces, there’s no reason that you don’t find a couple abstract classes in your code.

20 – ‘internal’ (VB.NET ‘friend’)
I’m a big fan of minimizing the public API published by an layer. In many cases, a public class, class member, interface or enum should really be internal. I’ve seen surface areas reduced by as much as 50%.

21 – ‘sealed’ (VB.NET ‘NotInheritable’)
There’s no reason to panic if you don’t find a sealed class in your code, but if you do, it’s likely a good sign.

22 – ‘GC.’
People who mess with the garbage collector are either very desperate to cover up a deep architectural problem, or simply think they know better than everyone else. Both of which spell doom for you.

23 – ‘Int16′ or ‘short’
More amusing than anything, this often indicates a micro optimization that’s actually going to cause a performance hit.  

24 – ‘(string)Request.Q’ or ‘Convert.ToString(Request.Q)’ (in VB.NET try ‘cstr(Request.Q’)
I wouldn’t have mentioned this obvious one had I not just seen it, but come on, my grandma doesnt’ unecessarily cast!

25 – ‘List<‘ and ‘Collection<‘ and ‘Dictionary<‘ (VB.NET ‘List(Of’ and ‘Collection(Of’ and ‘Dictionary(Of’)
If you’re working on an 2.0 project, I hope you’ll find that generics are being used throughout the code. They are by far the best new feature of 2.0 and it’s a shame if they aren’t being taken advantage of. (note, you could search for the System.Collection.Generics namespace, but I’m pretty sure the default C# template includes)

26 – ‘assert’
If you don’t get any hits, there’s little chance that the code in question was unit testing. Finding asserts doesn’t guarantee anything, but it’s a good start.

This entry was posted in Grab a coffee before reading. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

37 Responses to Have I inherited a disaster?

  1. Haacked says:

    I would amend #22 to point out that it may be ok if you see GC.SuppressFinalize within the Dispose method of an IDisposable class per the Disposable pattern as recommended by Microsoft for a type that implements a finalizer.

  2. Michael says:

    One point of conflict on #22. If you have to integrate at all with almost any Office product, you may end up having to specifically call the garbage collector. If you don’t, you end up with COM Interop issues. I was having some issues while integrating with MS Project, trying to get timescaled cost and duration data, and ended up having to specifically call the gc.WaitForPendingFinalizers.

    Just calling gc doesn’t automatically conceal a problem. There may be outside issues.

  3. Jeff says:

    RE: SP’s

    I diagree about SP’s being easier to maintain. Without any sort of versioning I think they quickly become a nightmare and “one more thing” to deal with when releasing builds.

    I personally prefer the use of paramaterized queries in your data classes. The caching for a paramaterized query brings the performance up to the same level as a stored procedure.

    (using “SELECT * FROM Users WHERE User_ID = @UserID” as apposed to “SELECT * FROM Users WHER User_ID = ” + userID)

    From where I stand the only argument, other than personal preference, for using Stored Procedures over a PQ is the ability to adjust security on a more granular level by specifying which accounts can execute which SP’s in SQL server.

    So I would have to disagree with you Karl. I don’t think that seeing “SELECT” statements in code is a sign of lazyiness or lack of knowledge of SP’s.

    Other than that though, an interesting read. I’ve seen many of the same things in projects I’ve inherited!

    The worst happened to be the following code (which I think is hysterical):

    StringBuilder sb = new StringBuilder();
    sb.Append(“Some text” + aVariable + ” some more text”);

    I think someone missed the point….. =D

  4. Wydok says:

    RE, SPs:

    We’ve been using SPs because it is easier to maintain the SPs than the inline SQL (having to set a string variable to the SQL and changing it all the time). SPs also help with hacking threats like SQL insertion. You can do that in code, too, but it’s handled almost automatically with SPs.

    Also, if it is discovered that an asp.net page isn’t displaying something correctly, and it turns out to be a problem with the SP, it’s nice to know that we can just change the SP on the customer database instead of having to install the code again (although this is more of an advantage with vb 6 dlls than with .net)

  5. Wydok says:


    Actually, no, there are no Java guys in this place. To be honest, I’m not sure where they got the idea from. We basically had one interface for classes that were supposed to represent one row in a database table, an interface for classes that represent a collection of rows in a database table, and an interface for classes that represent a task (a report or calculation). It was such a pain because in vb 6 you couldn’t have base classes, so every time we would implement an interface, there was repeated code. With .net, we have been deciding to go with base classes instead, so we only had to write code to check if a row is dirty in a base class.

  6. karl says:


    I think your point would be valid if I was picking on hungarian notation or something, but it’s hard to believe that x years from now, swallowing exceptions is going to be the "in" thing to do. Free’ing resources isn’t a "coding style".

  7. Sharbel says:

    Man, some of those items in that list really made me chuckle as I inherited 2 disaster projects this month. While everyone has made mistakes with coding approaches, you can always tell when people know what they are doing or not.. this list is a pretty damn good checklist!

  8. Cameron says:

    I will put T-SQL in my custom data class and skip Stored procedures whenever feasible. In other words, when the T-SQL is simple. Otherwise creating a new sproc just creates one more place that code must be maintained. And as others have pointed out, SQL Server is capable of optimizing base T-SQL statements whether or not they’re in a sproc.

  9. Travis says:

    “Isn’t the big benefit of using SPs that their execution plan is already known to SQL Server, so it’s much faster to run?”

    SQL Server 2000’s execution plan for dynamic sql is so optimized, the payoffs are *hardly* worth it. Now even more so with SQL Server 2005. That’s where the comment “They are so SQL 7″ comes from.

  10. Jav says:

    I am so tired of programmers thinking their coding style is better than everyone else’s.

    Surely in a couple of years somebody will pick up your project and say ‘What in the world was this guy thinking??’

    Sometimes is not about using all the latests language features but just getting the job done on time. We work on business settings dont we?

  11. Colin Blair says:

    IValidator is one of the interfaces in System.Web.UI and it was originally for use by the validator controls. Since then, it has been adopted for all types of development, not just web development. I discovered it on the Architecture board at asp.net.

    If you want an example of generics and templates being used in ASP.NET, check ColinBlair.com (which is currently down) this evening. I will put up a preview of some stuff I am working on.

  12. Alfred Hitchcock says:

    Nice one. All valid points though, good list.

  13. karl says:

    Alfred,I corrected the mistake so no one knows what ur talking about. HAR HAR!!

    Seriously though, the ‘P’ on my very new keyboard does not work well!

  14. karl says:

    wydok, quick question. Where the developers big Java guys?

    The .NET design guidelines say to favor abstract base classes over interfaces because they version better. Generally that’s good advice, but only generally. The docs should have more detail. Personally, I think it’s there specifically as a counter-point to the intensive interface design a lot of java developers do.

    The example that I’ve seen and reused is moving an object. Both a car and a person might be Moveable, but it probably doesn’t make sense to have them inherit the same base class. The mechanics for moving them is probably quite different. You might want any moveable object to have an IsMoveable(Location location); method. But determining whether Car X can be moved to location and Person Y can be moved to location is vastly different (ie, hopefully you don’t have to check the person for gas).

    As is often said about interfaces, what makes using an interface good in this case is that the only thing the methods in question share (IsMoveable and Move) is their method signature, the implementation is totally different. With base classes, the implementation is much more similar. The benefit, as others have pointed out, is that other code can easily Move both your objects because all they need is something that implements IMoveable.

    Interfaces are particularly useful in plug-in type architecture. It’s why HttpModules and HttpHandlers are implemented via interfaces and not base classes.

    I like what colin said about code reuse when using as opposed to writing. I plan on using that myself in the future! His example of IValidator might be because you need to validate a number of objects before saving to the database, in which case all you need is a collection of IValidator objects which you can call IsValid on. If any of them return a false (how the false was returned is totally up to the object) you can’t submit. With a base class, you tend to be more limited in the how you can validate yourself (because you inherit all the other plumbing of the base class).

    All that said, you don’t _have_ to use interfaces. They might not be very applicable in your case or they might not add much value. Remember though, it isn’t just about the chance that someone has of reusing your code, but how much reuse you do yourself.

    We generate custom reports (for a custom reporting tool) where we make it very easy to deploy new reports. All you do is create your own class, make it implement IReport (or IQuickReport) and the main code loops through all reports, and calls IReport.CreateReport(genericArguments) on each one. The calling code never knows anything else about the class, nor does it have to.

  15. Alfred Hitchcock says:

    27 What about programmers who believe that they are perfect and spend their time trying to show up others? 😉

    “13 – ‘HttContext.Items’
    The HttpContext is a new introduction to ASP.NET and it’s quite powerful. Unfortunately it’s also quite underused. Seeing the variables stored and retrieved from the HttContext.Items collection is an good sign”

    I’m not sure ‘HttContext.Items’ would build correctly lol. But then none of us are perfect, it’s just most people (and computer people in particular) like to think they are.

  16. Al Chumley says:


    > just the fact that anyone writes SPs in a OO application is beyond me.


    > In my experience a reliance on Stored Procedures is either A) A policy decision not based on technical factors 99% of the time, or B) A sign of a programmer who hasn’t embraced OOP and SoC. Don’t write inline SQL, but don’t write Stored Procedures either.

    Please excuse my aparent ignorance, but what other ways are there to integrate SQL into an app? What is SoC? (a Google search revealed nothing.) Also, what does OO have to do with it, other than strict type casting to help with things like SQL injection. Isn’t the big benefit of using SPs that their execution plan is already known to SQL Server, so it’s much faster to run?

  17. bobwantstdd says:

    OK, at least I have a decent handle on OrderHeader and OrderItem classes. I was trying to figure out how / why to make them interfaces. At least now I have feedback that they WOULDN’T be interfaces!

    Question, what is this IValidator you speak of, as if I should know of it? Got a URL to point me to? Is it a pattern or something obvious I should have run across by now? I don’t know it, so please point me to it?

    Not sure i understand you about child forms. are you writing winforms or webforms? I mostly deal with webforms, so winform structure/reuse/stuff doesn’t apply to me too much.

    I would love to see an annotated sample of using interfaces with master and child pages. ( Heck, I’ll even take an UN-annotated sample , so long as it makes sense! )

    I would love to see your source code if you can post it as an example.

    OK, it’s late, I can’t formulate real thoughts anymore, and the three ginntonics I’ve had since 9 PM (midnite now) have NOTHING to do with my lack of comprehension!

    Thank you all for the attempts at resolving my apparent ignorance.

    Maybe you’ll all have the patience to attempt to educate me further. Obviously I need it!

    Thanks again!

    DOH, one last point, I’m constrained to use .net 1.1 at this time, so please temper any responses appropriately.

  18. bobwantstdd says:


    I’m not sure what you mean “code against the interface”.

    When I fill my dg’s I call a method in my db class, filldgx ( or whatever, i normally name them a bit better… )

    That method returns a datatable. Sometimes i’ll return a named dataset if there is a specific reason.

    The guy who wrote stuff before me seems to have been engaged to sqldatareaders, and I’m converting away from them as I can.

    One of the things I’ve been seeing is these interfaces, all over the place. I just don’t seem to be getting it. I would LIKE to get it.

    What I just don’t seem to get is WHY these interfaces are such a great thing?

    I can get a datatable to fill my dg in a repeatable ( yeah, copyable at this point in time. shame on me, but I have it structured to copy really easy. changing this is on my todo list…) way. Takes me about 1 minute MAX to get a dt to fill my dg. ( by copying the fill code that is… )

    Someone tell me WHY I need to change this? I’m pretty darn happy writing code to fill my dg in under a minute. ( assuming the sp is already written.)

    In the case of large numbers of parms, I found a cool tool, forget the name ATM, that is easily updated, that’ll generate all the parm.add statements.
    I can write an SP, the class to hold it, and the DB functions in 30 minutes, from SCRATCH. This is GREAT for me. Especially since there is no docs for the DB on the project I am on right now.

    Someone show me how using an interface can improve on this?

    Perhaps I didn’t mention this, and it might be extremely relevant, but the possibility of someone else re-using what I write is about 10% The possibility that they will understand what I do and re-use it, the way I do it, is 100%

    Again, maybe I just don’t get it, which obviously I don’t.

    Someone give me a 100% complete example of where an interface would be really useful. Explain it it in doofus terms if you feel it necessary based on my comments. I Promise not to be offended.

    I feel I’m missing something important, and not seeing the light.

    If you try to explain it to me,give me ALL the code, please don’t assume I know what you take for granted.

  19. Colin Blair says:

    First off, your naming is helping cause your confusion. OrderHeader and OrderItem are not interfaces you would have. OrderHeader and OrderItem are seperate objects that you should have your own instances of. Interfaces are more about code reuse when using your class and less about code reuse when writing your class. For example, if you implement IValidator on your class, you will have to write Validate, ErrorMessage, and IsValid yourself, not much code re-use there, but then when you actually use the class you can pass it into reusable code that understands IValidator. For example, lots of error reporting systems take in objects that implement IValidator. We use an interface for every child form to create a common interface that our master pages communicate to them with. We could do the same on the master pages if we needed to have multiple master pages. Using interfaces for this is very safe, unlike defining our own page object. Partial classes in general make interfaces essential. It is difficult to change the base class of a DataSet, it is easy to add an interface in the partial class. For example, adding IValidator to the DataSet and DataTable make the DataSet a lot more powerful.

  20. Travis says:

    In my experience, people who use inline SQL statements simply haven’t bothered to learn how to use stored procedures. Now you get to pay the price for their laziness.

    Not writing SPs lazy? I’d say *smart*. (not refering to inline SQL lazyness), just the fact that anyone writes SPs in a OO application is beyond me. They are so SQL 7.

  21. Lee Barnard says:

    Nice article.

    I’ve just finished working on a mid-sized ASP.Net 2.0 driven website – which is my first major project with the 2.0 framework, and I’m pleased to say that I haven’t found any of the problems, and have used a variety of the other concepts (such as httpHandlers to deal with an interesting content sharing problem I had, with multiple countries and distribution channels sharing common language content).

    The only point I’d raise is 11, in some cases using the HTML Table class (and TableRow and TableCell) makes what you are doing codewise when building a table quite obscure. So much so, that I have left in comments the original HTML that I am creating around the Table class methods so that it’s easier to maintain. I think I’m probably still suffering from ClassicASPitis, and can’t get my head properly around the new way of doing these sort of things…


  22. foobar says:


    The great advantage for an interface is that you CODE AGAINST THE INTERFACE, INCLUDING YOUR CLIENT CODE.

    For instance, I bet you’re passing around SqlDataReaders like crazy in your code.  The problem is, if you want to use something like that, say, the TableDataReader, you’re hooped on your method arguments because they expect a SqlDataReader, even though a TableDataReader works _exactly_ like a SqlDataReader, because BOTH of them implement the IDataReader interface.  So, in your method arguments, you ask for an IDataReader, NOT a SqlDataReader.  The beautiful thing about this is that the type that accepts the IDataReader can _only_ code against the IDataReader interface, _even if_ the type that implements the IDataReader has other functionality.  That’s called _encapsulation_, folks.

  23. bobwantstdd says:


    I’ve been seeing interfaces everywhere I look. I’m even going back to basics to look at them some more.

    No matter where I look though, I’m just not GETTING IT as to why I’d want to use one?

    So far, I’ve come up with the following reason. Create some, put them all in a class with an actual implementation, then inherit/override that class as necessary.

    The problem I have, and I think it’s simply a question of scale, WHY would I want to do all that extra typing for the interface(s) when I could just put it in the class to begin with?

    Yes, I understand that an Order class might contain implementations of say OrderHeader and OrderItem interfaces, but wouldn’t I have less typing to do if I just created OrderHeader and OrderItem classes, then place instances of them into an Order class? Is it classes using other classes that is so bad?

    This is becoming an issue to me to “get” for other reasons, but maybe someone can shed some light here on exactly why interfaces are so great and how they help.

    Oh, I’m speaking from an asp.net perspective, not any flavor of winforms.

  24. Steven Cummings says:


  25. karl says:

    I’m pretty sure only Team System has the integrated FxCop.

  26. Darren Kopp says:

    hehehe, sounds like you will be busy if you wrote a post like this…

  27. Steven Cummings says:

    You recommend FxCop, but isn’t it now part of Visual Studio 2005? Maybe I heard wrong. Thanks.

  28. Colin Blair says:

    I don’t know about populating GridViews, but I do use SqlDataSource for filling dropdownlist, radiobuttonlist, etc. where I want to use the automatic caching features. I would never use the SDS for any primary tables.

  29. wydok says:

    We used Interfaces to the point of total pain in VB 6. A lot of that code can be in base classes instead. Interfaces are useful, but only in certain situations.

  30. soccerdad says:

    I disagree with the SqlDataSource comment. I wouldn’t use it for anything that does any kind of updating. But for populating GridViews from a stored procedure, they’re both safe and useful.

  31. Nick Parker says:

    I tend to question ‘sealed’ classes, Michael Feathers recently talked about the issues with ‘final’ in Java and metions sealed classes in .NET as well.


  32. karl says:

    Int16 can certainly be valid. My AMF.NET project uses it a lot because the Macromedia AMF binary format requires it. I just happened to be looking at code that seemed to be doing it for no reason and I remember it not being the first time…so I had to put it in.

    For you testing question, I want to preface my answer with a little note. First, I’m not a unit test expert by any means. Secondly, and more importantly, I don’t think that unit testing should be accomplished at the cost of design/architecture. For example, I worked on a project where a chunk of the ASP.NET framework was rewritten in order to make unit testing easier. Unfortunetly, it made writting actual code harder – that’s a big no-no in my world.

    VSTS unit testing allows for testing of restricted methods via reflection. Even if you aren’t using VSTS, you can accomplish the same thing in your own tests.

    You can always put the unit tests in the same assembly, which I know a lot of people hate doing.

    I know some people have thrown around the possibility to use partial classes or preprocessor symbols too…

  33. jmiller says:

    Nice post

    “22 – ‘GC.’
    People who mess with the garbage collector are either very desperate to cover up a deep architectural problem, or simply think they know better than everyone else. Both of which spell doom for you.”

    So true.

    I feel your pain –> http://codebetter.com/blogs/jeremy.miller/archive/category/1258.aspx

  34. karl says:

    Julien, that’s a mistake that’s been corrected by Microsoft. You can see http://blogs.msdn.com/fxcop/archive/2006/04/05/569569.aspx for more details. Though for the purpose of completeness, I’ll update it to also include ApplicationException

  35. Rik Hemsley says:

    ‘Int16′ or ‘short’

    There are three legitimate reasons I can think of where you might want to use 16 bit numbers:

    – Dealing with some binary data efficiently, e.g. CD format PCM.
    – Dealing with some binary format which was designed to save bytes here and there.
    – TCP Port numbers.

    I’d be interested to know how you reconcile 26 and 20. Do you have any tips on good test coverage while keeping API to the minimum necessary?

  36. Julien Adam says:

    Nice list! I think I’ve encoutered every single item in the list way at least once and way more often that I would have liked.

    I’ll just point out that according to the MS guidelines you are supposed to derive your custom exceptions from ApplicationException, not Exception.

    Cheers !

  37. Sam Smoot says:

    I’m mixed on the “using” comment. If you’re talking about file handles that’s one thing, but I think they’re overrated generally speaking (specifically most examples seem to involve SqlConnection instances).

    So you’ve got a strong argument if they’re used to invert the chain of responsibility to close file handles, flush NHibernate Sessions, etc. But I’d be careful about the context since I think overzealous usage is a little more akin to your GC argument (which I completely agree with; mostly 😉 ).

    (#8 DataAccess): In my experience a reliance on Stored Procedures is either A) A policy decision not based on technical factors 99% of the time, or B) A sign of a programmer who hasn’t embraced OOP and SoC. Don’t write inline SQL, but don’t write Stored Procedures either. If you can’t map it for some reason, at the very least code-gen it. Don’t fracture your code-base unnecessarily; it does nothing for the bottom line.

    But generally I agree, great post. I’d love to share a beer and duke it out sometime though if you’re ever in Plano. :-)

    Oh, and everyone knows *closures* are the best feature of .NET2… Generics… pift… 😀

    About Generics though: Using them, sure; but if you’re writing your own that’s somethin’ I think.