What Part Of The Process Are Your Tools Optimized For?

(This post is meant to be a tad humorous, so take a deep breath before you read it)

I’m writing this post because I am getting tired and weary of people pointing to "drag and drop tools", "visual designers", and "wizards" as reasons to use a particular tool. Only in Microsoft-land are developers so enamored with "wizards" and "drag and drop" and I think this is because Microsoft is the proverbial "crack dealer" when it comes to providing these tools.

The problem that I have with these tools is that they are designed to get you up and running quickly, but often to the detriment of your later development. How many of the tools that you use which have wizards or visual designers let you go back and edit what is produced? And if they do let you edit what is produced, how many of these tools will then let you go back and use the wizard or visual designer after you have made modifications? I would be willing to bet very few.

And lets think about why this is…. how come a visual designer can map out a complex process or schema, but then is unable to let you edit it? The simple answer is that our textual languages are far (far far far far) more expressive than any visual designer could ever be. Think about that for a second. Let’s use the Entity Framework as an example, (I hate to keep picking on it, but I have been dealing with it a lot lately) the graphical designer in the Entity Framework is one of these tools that is optimized for getting you up and running quickly, but this is done at the detriment of later flexibility.

With the Entity Framework, assuming that I already have my database schema complete, I can point the graphical designer at the database, generate my entities, and I am off. At this point I am ready to start creating and saving entities. This all seems great until I realize that I am severely limited by the generated code the EF spits out. (In VS 2010 they are planning to let you use T4 to customize the generated classes, but I’m not sure that this really solves the issue, it just ties me to different code) If I do decide to edit the generated code, then I lose the designer. So what if we do lose the designer? Is that all bad? Well, it wouldn’t be if the tools weren’t designed around having the mapping files and code generated.

I may take some heat for that last statement, but if you look at the mapping files, build tools, etc… You will start to see that the EF was never really designed to be used without the tools they have created. Think about it, because of the fact that they assumed that tools would be used, they put in place constraints that never would have been accepted otherwise. They descend from a standard base class (which is technically optional), they require that strings be passed for property change tracking, there is no automated change tracking, relationships require that you pass in foreign key names and entity set names, they require a custom key to be on your entity, you can’t use factory methods, etc… If they didn’t expect for the EF to be used without their tools, then they sure created a headache for developers that don’t want to use them. They allow for the EF to be mostly used without a lot of the generated code, but they certainly didn’t optimize for this scenario.

In effect what happened is that the Entity Framework is optimized for the start of your project. They assume that you have your database schema all mapped out, then you point the tools and bam! Sorry, I got a little Emeril in there. So you’ve stood this project up really fast, but I would say that the vast majority of the complexity in most projects comes out of the complex business logic and processes that are introduced into it, not the basic layout of the domain entities. As time goes on and you need more and more logic and flexibility in your domain layer, the last thing you want to do is be held back by your persistence technology.

The solution that some people have pointed out is to simply use EF or Linq to Sql generated objects as DTO’s and then map the data back onto your business objects. This actually seems to work okay in many cases although it seems to me that we are doing a lot of work for the ORM that it should be doing itself. If you are looking into this solution, then you may want to check out the December 2008 issue of MSDN magazine where there is an article titled "Flexible Data Access With Linq To Sql and the Entity Framework".

To illustrate the importance of not optimizing for the beginning of the application construction process we are going to start off with a completely ridiculous and overly simplified graphic:

This is what I call the software product construction pipeline. And like I said, it is completely ridiculous, and totally not drawn to scale. What would it look like if drawn to scale? Well, probably something like this:

I would have made the "beginning construction" part even smaller, but I figured I’d leave a little bit in there for argument. Now keep in mind that I am just describing the actual construction part of the application. You may be wondering what happened to the "Ending Construction" piece from the first graphic. Well, I forgot to tell you, but that part doesn’t exist. No project is ever really finished.

So now that we are agreed (well, you better agree) that the beginning phase of our construction is much smaller than the total of construction, lets go ahead and describe what "beginning construction" is. Doesn’t this sound like the way that most projects are planned out? Beginning construction is about getting the environment up, getting basic layout planned, and getting to the point where you can really start digging in and developing your application. "Construct" is all about building the thing which you set out to build.

So what part of the process do you want to optimize for?

This guy…

Or this guy?

I trust that you’ll make the correct decision.