Jeremy D. Miller -- The Shade Tree Developer

My friend needs some help on an article

Jeremy D. Miller — Wed, 07 May 2008 05:03:00 GMT

I would never do this, but a "friend" of mine has procrastinated entirely too long and let a deadline for an article sneak up on him. Here's a couple ideas that my friend has for his next article. The article has to be on design fundamentals from a relatively ideology agnostic standpoint (not overtly pro-Agile or TDD in other words). His first article in the series on the Open/Closed Principle will appear next month. Please think about which topics would benefit your team members too, Mr. "I know the basics cold" Alpha Geek.

"Design Vectors" / "It's the Little Things" / "A title that doesn't stink" -- Why do you care about Encapsulation, Coupling, and Cohesion. Then follow up with some heuristics to push your design towards these qualities. Tell, Don't Ask, Law of Demeter, Don't Repeat Yourself, and a bit on some Code Smells. My friend wants to sneak in an example of using a lambda expression to remove duplication. Yes, Mr. Alpha Geek, you've read the Pragmatic Programmer front ways, backwards, and sideways, but this is for a more general audience.
Creational Patterns -- Builder, Factory, Abstract Factory. Then talk about using an IoC tool as a generic way to implement these patterns. The importance of separating functionality from the grunge work of assembling object graphs. My friend isn't that excited about this one.
Object Stereotypes -- An introduction to the idea of object stereotypes from Responsibility Driven Design. Apply these stereotypes to some bigger patterns like MVC/MVP. It's an under appreciated topic.
Inversion of Control as a Pattern -- Forget the IoC/DI tooling. Let's talk about how, why, and when this pattern is useful.
Patterns for Persistence and Data Access -- Lots of stuff from Fowler's PEAA book. Unit of Work, Database Mapper, Active Record, Row & Table Gateway.

Anything sound good to you? My "friend" would appreciate some opinions here.

Would you do it differently today?

Jeremy D. Miller — Thu, 01 May 2008 15:04:00 GMT

A year and a half ago I wrote a post called My Gameplan for Starting a New Project from Scratch that just detailed my thoughts on starting up a new project. I was asked via email last week if I had any changes to that post. Yes, absolutely:

Follow it Through!

Don't jump into the work too early without a good story backlog definition, an understanding of the goals of the system, and some inkling of the expectations of the client (which are undoubtedly going to turn out to be ridiculously unrealistic).

All processes, even XP and Scrum, have some sort of fuzzy project conception phase. The activities that you perform in that phase are crucial to the success of the project by preparing the field, but easy to neglect because there isn't much pressure upfront and the feedback loop that says "you're wrong!" hasn't started yet. On the other hand, I think you need to work with a sense of purpose early in the project to get through that initial phase and get started. In My Gameplan post I talked about the importance of getting momentum early on in the project. That's largely based on my experiences in a large organization that let the early phases drag on way too long. After doing three projects and starting a fourth since that post, I'd still err a little bit on the side of starting the coding in earnest too early rather than too late.

I did have some issues with coding outrunning the build, test, and deployment infrastructure. Take care of that stuff as early as possible. Especially early on the project, if you see chances to add some automation to reduce friction, do it right then. Investments early on pay off more in the lifecycle of a project.

Agile Antipatterns discussion

Jeremy D. Miller — Wed, 30 Apr 2008 21:36:00 GMT

From the Java side of the world, a dead on discussion on Agile Anti-Patterns. Been there, done that, gotten the tee shirt. I think I'd add:

Overly long stand up meetings and/or iteration planning meetings
Contention in iteration meetings
Not doing retrospectives or not acting on retrospectives. It's easy to skip when you're under duress, but you shouldn't.
Not doing estimation together
Not getting concrete acceptance criteria for a user story
Not pushing completed stories to testing until late in the iteration

A Train of Thought -- ALT.NET Seattle Edition

Jeremy D. Miller — Wed, 30 Apr 2008 14:18:00 GMT

Yeah, I'm a week late with this recap, but I've had writer's block. The Seattle ALT.NET Open Spaces event was awesome. The open spaces format is by far and away my favorite format now for developer gatherings. I love the interactive aspect of this format. We jumped right into a great set of topics without getting hung up in useless, angsty "What is ALT.NET all about?" discussions. I love catching up with people that I've met at other conferences and meeting more of my blogroll.

Ready or Not, Here comes the Polyglot Programming Reality

A major topic in Seattle was the Polyglot Programming trend (I know it was a big topic because I have a lot of notes that I can't read under the heading "Polyglot *********"). Right now there seems to be an explosion in new programming languages or at least interest in different programming languages.

There was a lot of discussion both about doing some or all project work with alternative languages like F# or IronRuby when it hits. The general idea being that you would probably write infrastructure code in C#, then use a more dynamic language like IronRuby for business logic and "glue" code in the upper layers. More on this later, but I think it's somewhat comical that we're calling C# the infrastructure language when a few short years ago it was C++ for infrastructure and C# was the high productivity language in the upper layers.

Would you mix languages on the same project, and if so, is that a good thing? There were a lot of mixed opinions on this subject. On one side is the fear that multiple languages will make a system harder to understand and require more skilled people to work on the system. Then there's the other side that thinks we'll get more productivity by having multiple languages that are specialized for certain tasks. Personally, I know I'd like to be able to easily mix and match C# and IronRuby on projects.

Complicating the discussion is the idea of little Domain Specific Languages that aren't even remotely Turing complete. To this point, I've been mostly interested in internal DSL's using Fluent Interfaces in C#. I look at that technique as merely a stopgap until we get IronRuby and its far superior language support for DSL's. The next bit of evolution is dabbling the toes into creating an external DSL. I've always been leery of trying out some sort of lexical parser ala YACC or ANTLR, but the Language Workbench idea coming from the JetBrains MPS product is very intriguing. Imagine being able to write your own focused mini-language for test automation or configuration without losing Intellisense or basic refactoring. That's what the Language Workbench products will eventually do for us.

There's a rumor that Microsoft might be interested in creating some sort of Language Workbench as part of their DSL efforts. Thumbs up from me, but please don't ruin it by making us use XAML.

Before you panic about the difficulty in learning new languages, think about this: is a tightly focused mini-language DSL going to be any harder to learn than the equivalent new API in C# or VB.NET? In many cases I'd argue that an internal DSL is preferable to an old fashioned API in C#. Web programming with HTML and CSS was brought up as an antipattern because of the 3+ languages you have to know to develop. I'd turn that around and say that web programming is a great example of polyglot programming. Try to imagine what the C# equivalent would be like for replacing HTML and CSS. I think I'll take HTML and CSS, thank you.

Quick Hits

These should be on Twitter but I just feel weird shooting these things out in 140 characters at a time.

Code Generation versus Code Synthesis. I think that one of the big debates in software development over the next couple years is going to be over pursuing better productivity through external tools like software factories and large scale code generation or by using different programming languages (I.e. not Java/C#/VB.Net) that have facilities to write much less code. In this corner is Kathleen Dollard on Code Generation. And in the far corner is Venkat Subramaniam on Code Synthesis (using Metaprogramming and language oriented programming to pack more punch with less code). I'm with Venkat on this one. Why do I want to muck with a separate model outside of code, then run the code generator if I can work at the same high level directly in the code itself? Of course, to be a loud debate, the two sides of the issue would have to know that the other side even exists. Today, code generation probably seems like the default choice in .Net development because we don't have programming languages that support Venkat's vision of Code Synthesis. When IronRuby, IronPython, and F# are ready for production, Code Synthesis in the .Net space can be a reality.

Microsoft employees are a little too cloistered for their (our) own good. Not all mind you, but many of the blue badges I interacted with didn't have very much prior exposure to many of the topics that come up frequently in ALT.NET settings. I get it, it's a big campus full of smart people and you're probably heads down on your own project. Case in point, in ALT.NET circles we seem to be much more enthusiastic about Language Oriented Programming with textual DSL's (or at least that's my position, preference, and observation). In Redmond, DSL == graphical tooling backed up by code generation.

After this weekend, I really think the concentrated blogging communities like Los Techies, Elegant Code, and yes, CodeBetter, are a very positive thing.

Why are teams still writing persistence code by hand? There's a bazillion persistence tools out there that all save development costs in some way over writing data access code by hand. With very few exceptions, I'd say that at this point that if you're writing ADO.Net code or SQL by hand, you're stealing money from your employer.

I wasn't there, but there was a session roughly titled "Are Auto Mocking Containers Evil?" I had this argument a little bit with Scott Bellware the other night, but it came down to a problem with wording. He heard the word "container" and had awful images of Xml configuration hell. All an AMC does for you is look at the constructor of a concrete class and use Dependency Injection to stuff in test doubles for all of the parameters in the constructor function. I'd urge you to approach an auto mocking container (AMC) as simply a tool to reduce the mechanical cost of setting up interaction tests. I initially resisted the AMC idea because I thought it would obscure the unit tests, but I'm sold on the AMC technique after using it for awhile on a project. A class with a lot of collaborators is a code smell, but remember that code smell doesn't automatically mean there's a problem. Some Controller-type classes do absolutely nothing but coordinate other classes. Unit testing those classes will require two or more mocks in a single test.

I seriously think you should seldom use your IoC container inside unit tests. The mass majority of interaction unit tests should be easy to set up with pure DI. I say this for two reasons. First, the IoC container is infrastructure code and you want as little code as possible directly coupled to the container. Second, using a container inside of a unit test greatly ratchets up the risk of test data from a previous unit test polluting the results of a later unit test. Unit tests need to be isolated for effectiveness, and using an IoC container in unit tests can easily abrogate that isolation.

StructureMap and StoryTeller plans

Jeremy D. Miller — Wed, 23 Apr 2008 13:24:00 GMT

Just a quick update on stuff because I got a lot of questions about StoryTeller over the weekend. I'm currently focusing my attention on StructureMap. I'm giving it the Python 3000 treatment and pretty well gutting some of the internals to clean up the structure. I've eliminated some obscure features, but you're perfectly safe if you use the documented public interfaces. Once that's done, I've got just a little bit more functionality to add and I need to rewrite the documentation. I gave an impromptu (and it showed) session at ALT.NET Seattle on my lessons learned for extending a framework over 4+ years. I'll write a paper of some sort on that this spring.

As for StoryTeller, I got quite a bit of interest in it over the weekend and I've had a couple emails lately as well. I was close to giving up, but some of the things on the horizon that I thought would eliminate its usefulness turned out to be Java only or so far over the horizon to be effectively nonexistent. The engine such as it is has been done for almost a year. I'm going to rewrite the skin of the UI in WPF just to get my hands a bit dirtier with WPF. I've done enough experimentation with some crude Intellisense for Fit tests to say that I'll be able to make Fit test editing much more efficient. I'll update again later this spring.

A Train of Thought -- MVP Summit 2008 Edition

Jeremy D. Miller — Wed, 23 Apr 2008 12:04:53 GMT

Just jotting down my notes from the MVP Summit (so I can get on with ALT.NET commentary). I haven't seen anything revolutionary, but the conversations are always the best thing anyway.

I'll sum up the entire summit in one word: positive. I thought that the interaction I saw with Microsoft was simply positive across the board. Not perfect mind you, but I'm content.

Here's what I saw (no names and some specifics omitted for NDA compliance):

I'm still not thrilled with the Entity Framework and the direction they locked themselves into, but the EF team came prepared to talk about some compromises that might start pushing EF into the usable category for me. I honestly wouldn't care about the EF, but I'll probably be back in consulting at some point in the next 5 years at a shop that will only use Microsoft tooling.
Daniel Simmons gets the "Thickest Skin of the Year" award. Not the Hyperion/Endymion Dan Simmons though.
I enjoyed the IronRuby and IronPython talks
The Parallels extensions to .Net are intriguing, but I wish they'd shown more code and fewer slides
A version of the Open Spaces format was used for some of the MVP Summit. It wasn't the real deal, but I'd say that it was an improvement. I really appreciate the more interactive formats as opposed to passive watching the slides go by talks.
Getting asked for some real feedback. Ayende & I got to see behind the curtains on some internal work in the .Net framework that I was pretty happy about.
I did hear about one thing in the works that has the potential for some community backlash, but they seemed to be interested in reaching out to defuse that backlash.
The language teams are very serious about ramping up the coding centric features in the Visual Studio IDE. I know a lot of .Net developers think that Visual Studio is the greatest thing since sliced bread, but it's coding features badly lag Eclipse or IntelliJ from the Java world. It's nice to see Microsoft starting to work on that gap. I don't know if they'll do anything that isn't already in ReSharper, but I'm looking forward to seeing where they'll go.
Listening to no less than Brad Abrams say that they're taking testability into consideration on all .Net framework design now. Cool.

What I want for Christmas from Redmond

IronRuby! Even without Rails, I'd love to use RSpec for testing .Net code and writing specs. DSL construction on the CLR, here we come!
I don't know if it'll ever catch on, but F# looks seriously cool
Transparent lazy loading in the Entity Framework. If they want the Entity Framework to be usable in constructing rich Domain Models, they're going to have to do this.
A hook in the Basic Class Library to make the choice of IoC container pluggable. I think it makes a lot of sense for the .Net framework to have some sort of IoC container capability built into the framework, and you know they're going to do it at some point. Acropolis needs it. Prism needs it. MVC needs it. Heck, even plain jane WPF could use it. Just please make it pluggable when you do that at some point in time.

Rightsizing your approach

Jeremy D. Miller — Tue, 22 Apr 2008 14:52:00 GMT

My last post, I might be an elitist, but you're a misanthrope, has kicked up a great conversation in the comments. There's one viewpoint in the comments that I'd like to challenge a little bit. What if I'm working on small projects with very tight timelines? Many of the subjects that fall under the ALT.NET umbrella of interest like IoC, ORM, and AOP wouldn't seem to be justified on a smaller project. Fine, maybe not, but the more basic design fundamentals that ALT.NET is also championing definitely apply to every project longer than a couple hours.

I've seen plenty of systems that were negatively impacted by code quality or a miscast application architecture. Roughly, I'd say that the two worst type of offenders fall into two general camps:

Overengineered. Way too many abstractions that didn't add value but did add complexity. Some of the problem is just creating the wrong abstractions and the wrong model, but much of that could be explained by using the tools from a large, complex development project on a smaller project where the tools weren't justified.
Underengineered. Brute force coding with little or no thought for abstraction or layering. By only using simplistic techniques or straight up procedural programming you may be writing way too much code and exerting too much energy. On a larger project finding the pertinent code can be a major challenge in its own right. Just throwing all the code into a bag full of very large coding modules isn't going to scale. The danger to me in that "just Git'R Done" mentality is the fact that that attitude fails when you hit a bigger project. The biggest mess of a system I've ever encountered was a VB6 COM(+) system that began its life as a prototype and was rushed into becoming the shipping automation system for a Fortune 100 company. Typical circa 1998 VB6 methods of code construction didn't scale to a system with 250,000 lines of code. Sometimes you need to reach for the more advanced techniques.

Admittedly, most of the biggest and craziest messes I've seen (including one of mine) fell into the first category, but the "under" category is just as much a source of wasted effort in software development today -- even on smaller projects.

Most of us live under unreasonable timelines and expectations (do remember that Agile project management was partially created to give us a saner control over those very expectations). Yes, I think that the scale of smaller projects and problems doesn't justify many of the same design patterns that I'd call mandatory on a larger project. I've reviewed several smaller solutions lately that were churned out in a hurry. In many cases I found places where the author of the code just plain wrote too much code. There were opportunities to pull out commonality into shared code (Don't Repeat Yourself). Using the Composed Method pattern would have made the code much easier to follow when that code needed to be modified 6 months later. IoC/DI/AOP/DDD wouldn't have been very useful in these projects, but a true working competency with OOP fundamentals would have cut the effort required to execute these projects.

My only point is that even small and quick projects can benefit from developers with a better skillset and knowledge. At a bare minimum, just knowing about existing libraries for common tasks would be helpful so you spend time solving the actual problem instead of rewriting log4net (true story) or wasting time writing ADO.NET code by hand (I honestly think I can use NHibernate easily enough that I would still use it on small projects). Even simpler projects need to be approached from a "Work smart, not hard" perspective.

To this quote from Andrew Tokely:

Should an application that has to be built in a month, will only be used by a handful of people, that will be rebuilt by something newer and better within a year or so, that doesn't have complex workflow or business logic, that really only needs to persists data back to a datastore... really need to contain the level of abstraction and testability of other projects?

No, the system he describes doesn't need quite as much abstraction and layers and whatnot. Testability in some ways equals "the ability to quickly gain feedback on the correctness of the code," so yes, you definitely want "Testability" in order to work efficiently at any time. In the case of a smaller system just pressing F5 might achieve the goal of quick feedback just fine -- but if F5 isn't enough feedback, you do need to care about "Testability" in design. Duplication of code, verbose code, and poor structure can still hamper even the smallest, simplest application in a way that detracts from your ability to execute in a timely manner.

I might be an elitist, but you're a misanthrope

Jeremy D. Miller — Sun, 20 Apr 2008 15:21:00 GMT

I've been in Seattle the past week, first at the MVP Summit and now at the ALT.NET event. It's been good to rub shoulders with folks from outside our little ALT.NET cocoon to hear other points of view, but there's a particularly common refrain that bugs me a little bit. It goes something like "that's great and all for you alpha geeks, but what about Joe Schmoe corporate developer at BIG CO?" The obvious implication is that the average .Net developer just isn't capable of grokking things like OOP fundamentals and some of the coding techniques we use in Agile development. My pre-canned response is generally something along the lines of "if they can truly understand the page event lifecycle in ASP.NET WebForms, they can learn anything!"

In all seriousness, every shop that I've worked in or with that cared about the strength of their people had plenty of strong people. Some of that was due to hiring practices, but a lot of that can be attributed to a culture that enabled and encouraged developers to get better and learn new things. I think there's a little bit to the idea that people perform up to or down to the expectations placed upon them. If you really say to a developer that I think you should know some design fundamentals, I think the average developer would very quickly know those design fundamentals. I'd really like to see the .Net community as a whole start to be a little more optimistic about the abilities of the average .Net developer so we can get on with the business of getting better collectively.

See you next week in Seattle

Jeremy D. Miller — Fri, 11 Apr 2008 15:33:00 GMT

I was originally only going to the ALT.NET event in Seattle next weekend, but now it looks like I will get to attend the MVP Summit as well. See you there!

Things really are changing in the .Net community

Jeremy D. Miller — Mon, 07 Apr 2008 15:58:00 GMT

Check out this article about the rationale for the ASP.NET MVC framework on Dr. Dobbs. Absolutely nothing you haven't heard before, but it's written by Dino Esposito. It's fine and all to hear this sort of thing from ALT.NET leaning outliers, but Dino Esposito is virtually Mr. Mainstream in the .Net developer community. Cool.

So what am I doing for my first week of blissful unemployment?

Jeremy D. Miller — Sun, 06 Apr 2008 14:24:00 GMT

I sat down this morning with my notes for the StructureMap 2.5 release to reacquaint myself with the remaining work I wanted to do before the release. I wanted to just work through the punchlist, but this irresistible voice started saying "rewrite the InstanceMemento/MementoSource mess." So apparently, the answer to what I'm going to do today and tomorrow is "rewrite a significant piece of the StructureMap core code that's accumulated trash code over 4 years." The usage of the tool and what I want it to do is so different from where I started in the summer of '03 that it's amazing that that code lasted this long.

Before I even start, let's say hooray for Subversion and automated test coverage, cause I bet there'll be some misfires along the way.

That's step 1. Step 2 is to take the family to the San Antonio zoo on some random day during the middle of the week. Life is good.

The unmentionable subject

Jeremy D. Miller — Sun, 06 Apr 2008 14:00:00 GMT

I've been accidentally cut off from the altdotnet discussion group over the past couple days and I wanted to catch up this morning. Unfortunately, the first thing I see is a conversation about to Stored Procedure or not. Not gonna join in or even going to read. There's been absolutely nothing new written or thought about the subject of sproc's for years. I'm happy to agree to disagree with the sproc advocates and peacefully go on our separate ways. There was something in the water about 3-4 years ago that allowed some of us in the Microsoft developer camp to convert away from sprocs, but those conditions are apparently gone now.

Just let it go.

I'm a free agent

Jeremy D. Miller — Wed, 02 Apr 2008 19:21:00 GMT

I quit my job today, and it's been one of the best days I've ever had. It's felt like a large weight lifting off of my chest.

EDIT 4/5/2008: Chad & I are still getting some nasty emails, so I've removed everything that could possibly give our former boss anything to complain about.

Anyway, no worries on my account, this couldn't have possibly have happened at a better time personally, and I've already had some good looking leads and a very positive interview earlier today. If you're interested in engaging a Shade Tree Developer for short term consulting, feel free to drop me a line. I've got to go permanent at some point before August (mortgage lender wants me to be a perm), but I'd really like to try the solo thing for a little while. I've got some downtime, so I might finally get to finish some side project work.

I might even manage to start answering emails in a timely manner....

In honor of Greg Young

Jeremy D. Miller — Mon, 31 Mar 2008 00:41:00 GMT

We need ALT.NET to supplement the traditional .Net leadership

Jeremy D. Miller — Sun, 30 Mar 2008 20:34:00 GMT

One of the roles I’d like ALT.NET fulfill within the greater .Net community is to be a second pole of leadership and thought. I say a “second” pole, because the .Net community already has a long standing traditional leadership -- the book authors, the MVP’s*, the INETA speakers, and whatnot. They’ve done plenty of good in regards to explaining how to best use existing and forthcoming Microsoft tools, but I think there are a lot of valuable subjects and viewpoints that are largely missing from the mainstream .Net dialogue. Specifically, I’d like to see ALT.NET start to fill what I see as a void for information and leadership on:

OOP fundamentals. I think we as a community would achieve far more benefits on our projects from a stronger base of OOP design knowledge than we do for learning new API’s like WCF or LINQ. Learning the fundamentals will make us far better able to choose and use these new API’s.
Development processes and practices. Microsoft builds and sells tools, and they naturally see tools as the solution to most problems. We the community should be completely in charge of determining our best practices because we are the ones out there building software. Go to a .Net centric development conference. Outside of some token Agile track, you will not see very much about configuration management, project management, requirements, testing, or the all important people issues. A lot of Linq to XYZ talks, but not much about running successful software projects.
Alternative tools. Some of the tools Microsoft makes are great, but some are inferior to non-Microsoft options. Some of these alternative tools open up entirely new possibilities in how we can work. I’d like to see the entire .Net community to simply broaden its horizons to be more accepting of tools originating from outside of Redmond.

Two recent podcast's illustrate to me why I think something like ALT.NET has some value to offer the community by filling holes in the dialogue. First up was Lerman on the Entity Framework on DotNetRocks. I promised Julie that I wouldn’t burn her in effigy here, so I’ll just say that I think that podcast covered the Entity Framework from a very data centric viewpoint that skated over some important concerns about using any persistence framework. Namely, what does this tool do to my business layer and the application as a whole? How much does the tool intrude on the rest of the application? From my own, very different viewpoint, the Entity Framework is conceptually flawed in some significant ways and won't let me work in the way that *I* think makes me the most successful:

In my opinion the new “conceptual model” in the Entity Framework that allows you to treat the database more as a set of hierarchical entities is a poor substitute for fullblown OOP programming. I think the conceptual model is unnecessary complexity that detracts from the usability of the EF.
The lack of transparent “lazy loading” in the Entity Framework is a dealbreaker for me. The need to explicitly say “Order.LineItems.Load()” makes the EF a very poor fit for Test Driven Development by making the EF objects difficult or nearly impossible to use independently of the database. Lazy loading should be completely transparent to the business logic, and I should be able to completely express the business logic without letting infrastructure concerns leak in (that Separation of Concerns thing). The podcast completely whiffed on this topic in the discussion of “POCO” objects at the end of the episode.
At this point, EF couples you very tightly to the database. Support is very weak at this point for Domain Driven Design techniques. I really don’t think the EF is usable without using codegen to bake in the change tracking code that EF wants to be in the objects. Codegen-ing your business objects pretty well eliminates evolutionary design or keeping your domain logic in these classes. I know you can use partial classes for the business logic, but that's sooooo clumsy. Besides, the codegen is more or less optimized for scenarios where you merely replicate the structure of the database in the object model.

Many people don’t feel that the EF picture is all that rosy, but those concerns simply aren’t getting much attention or understanding from our traditional community leadership.

The second podcast was .Net author Rocky Lhotka being interviewed on Hanselminutes about data access issues. I mostly agree with Rocky on the general goals, but I think there's better mechanical ways to achieve an effective object model strategy than what Rocky was espousing on the show. Rocky gets some serious points from me for talking about Responsibility Driven Design (my choice for the single most effective design technique) and the Single Responsibility Principle (SRP). Ironically enough though, I advise people against using his CSLA.Net framework in no small measure because I think CSLA violates the Single Responsibility Principle.** It may be that Rocky and I have vastly different interpretations of the SRP, but that again points to the validity of a second pole of thought and discussion because I really don't think that Rocky (or any one else including me) gets to be the sole voice who gets to define design best practices.

One of the other things Rocky said was that ORM tools tightly bind your object model to the database. His suggestion was to use an ORM as just a data access layer and manually write mapping code within your business objects to translate between the database model persisted by the ORM and your own domain model classes. I thought this was terrible advice in most situations because it's unnecessary, and putting that mapping code inside your business objects let’s infrastructure concerns bleed into my your domain logic code (a clear SRP violation). When I use NHibernate, I can write my business objects in a structure that fits the behavior of the business logic the way Rocky and I both want to, but I can also persist these objects to a database structure that makes sense for the database with very little impact on the business objects. I do not have any need to write all of that tedious mapping object-to-object code that Rocky was suggesting. I don't know if Rocky was purposely overlooking the capabilities of NHibernate or the WilsonORMapper in favor of his traditional CSLA approach, doesn't believe in ORM, or if he just flat out doesn't know. Either way, we need some alternative sources of information, and dare I say it, visible authority figures in the community.

Sometimes the Microsoft solution isn’t the best

Both podcast's were lacking in well informed opinions about alternatives to the Microsoft tooling on data access, and I think that's probably my biggest reason for writing this post. If my choice was really a binary decision between Linq to SQL or Linq to Entities and rolling naked ADO.Net code, heck yes I'd jump for joy about the EF. Fortunately for us, that's not the case.

The biggest problem for me with the EF is that I think there are simply better existing tools for the vast majority of projects. For simpler CRUD or reporting applications, SubSonic is basically the exact same kind of “generate strongly typed object wrappers around the database tables” solution as the EF and Linq to SQL, but I bet SubSonic would be much easier to use. LLBLGen Pro is much more feature rich than the Entity Framework. NHibernate is vastly better if you want to use a rich Domain Model approach for your design and/or want to most effectively utilize TDD. iBatis.Net will probably be easier to use for nastier legacy database schemas and give you ultimate control over the SQL with lighter weight mapping than the EF. Heck, LLBLGen Pro and NHibernate are well on their way to having full LINQ support, and SubSonic has a strongly typed query language, so shoot down that advantage for EF. My preference is NHibernate, but I was very happy with my usage of the Java version of iBatis.

I honestly believe that if we don’t have any useful alternative to the traditional .Net leadership, all of these arguably superior tools will be shoved to the sideline in favor of the deeply flawed Entity Framework. Worse yet is that we might not get better tools because I don’t think our traditional leadership does a very good job of giving useful feedback to Microsoft to help make these tools better. I really do believe that our traditional leadership largely sees new tooling as simply opportunities to write articles, books, and be visible conference speakers rather than something that needs to be carefully evaluated and possibly rejected. I want leadership that can help us make good judgements about how and with what we should build software instead of just relaying the guidance from our toolmaker.

Summing Up

I didn't say here that I think we need to completely swap out our entire leadership clique. All I want is an additional set of leadership types who are discussing other points of view to give us a more rounded conversation. To some degree, I think we might just need a new generation of leadership that didn't come up through Windows DNA programming. Lastly, I don’t really care if it’s the ALT.NET movement specifically that starts to fill this void as long as it’s filled by somebody in a useful way.

When some .Net poobah says that every class should be accessed through WCF, someone else should speak up and say "that's insanely stupid," but in a reasoned, adult like manner. And if any MVP speaker type says you should be using the Entity Framework/WF/putting all your business logic into XAML/whatever, I want to see some dissenting opinions too.

Comments are open. Feel free to disagree with me.

*To be fair, many of the most visible ALT.NET members, including myself and many other CodeBetter bloggers, are also MVP’s of one sort of another. I’d still say that we make up a very small minority of the total MVP lineup.

** To the CSLA proponents out there, I’m going to issue you a challenge. Run static code analysis numbers on your CSLA “business” objects. I’ll betcha that the Cyclomatic Complexity numbers are uncomfortably far into the dangerous zone – and yes, if this is so, this is something you should be concerned about.