I'm two weeks into a new project in midtown Manhattan, and I'm using the train rides to do side project things. Coming home this evening there are a couple things I'm thinking about, so here's a Bare Naked Ladies-style stream of consciousness blog post (my wife hates BNL for that, but I'm a fan).
Novelty in Your Design Deserves Extra Scrutiny
Innovation is a great thing, and the final book on software development is still in a rough draft. That aside, I want to urge a great deal of caution when you use any kind of design that contains elements of novelty. When you go off the beaten track, you need to be more reflective than normal because you're taking on additional risk. Is my new idea just a crackpot idea? Does it really provide any real value over boring, run of the mill patterns? I've seen too many grand, creative ideas go sour -- and a couple turn into big successes. By all means, be innovative and creative, but you better be watching the feedback from your innovation and be prepared to walk away from it if necessary.
The DNR Episode on the Entities Framework
I like DotNetRocks, but I don't often remember to listen to it very often. After Ayende and Scott both made some not quite positive commentaries on the podcast featuring Daniel Simmons (Microsoft guy, not the author of Hyperion) from the Linq to Entities team, I gave it a listen. I didn't hear anything on the show that particularly changed my mind about the Entities Framework. I still think it's a piece of very impressive technology that's saddled with questionable usability for the way I want an ORM to work.
The strongest comment I want to make about the episode is that I think the hosts didn't quite ask the right questions. Almost the whole podcast was data access this and sql that. Data access and persistence is a big issue yes, but to me the choice of persistence strategy is driven by the business logic first with performance a close second. The real question is how does the EF allow me to write business logic in isolation from the database? It's important to me to write business logic code in a way that makes that code easy to write, read, and test. My first step to meeting those goals in building a business logic intensive app is to isolate the business logic away from the details of the backend storage, and that's why the "NHibernate Mafia" wants Persistence Ignorance for our domain classes.
Oh, and I hate the dichotomy between business objects and entities. The very term "Business Object" is rife with ambiguity. I like the Evans terminology and mindset better. I have domain model classes (Entity in Evans terminology) and little "s" service classes for the things that don't fit into domain model classes. I think the old "Business Object/Entity" split reflects a largely procedural mindset where logic and data are two different things -- you basically have lumps of data (recordsets) and classes that manipulate those lumps of data. It's classical procedural programming.
OSS and the Long Tail
When we were at the MVP Summit we heard Don Box effectively blow off TDD/BDD/DDD as just passing TLA's. His contention was that Microsoft didn't, and shouldn't, favor any particular TLA style of development. I thought Don Box told a pretty big fib on that one. Most of the the tooling from Microsoft is built around RAD with a very obvious preference for a datacentric view of software development. Not because Microsoft is evil, or intellectually sluggish, or any other nefarious reason. I would guess that Microsoft largely focuses on the Visual programming paradigm because that's what Microsoft developers generally seem to want. In the end it's hard to argue with the fact that Microsoft is just doing what the biggest share of its customers want them to do. It actually sounds like good business practice to me.
You've probably been subjected to the Long Tail idea. The mainstream approach in .Net is RAD, but I don't want to have to work that way. I'm generally in the newly christened, and mildly self-deprecating, ALT.NET camp. Focus on the "ALT" -- as in alternative, as in "not the mainstream." I know full well that I'm going against the .Net grain in the way that I develop, but fortunately, there's a lot of OSS tooling to enable my preferred approach to software development that Microsoft tool simply do not. OSS is effectively the major source of diversity in software development right now. OSS development improves the practice of software development by giving us choices that divert from the Microsoft mainstream. There just can't be any one way that works for all systems. OSS tools are our Long Tail for .Net development.
Functional Programming
I wish I knew more about Functional Programming, and I'm finding myself using more anonymous delegates and wishing for C#3 lambda expressions. I don't know about FP taking over the world and replacing OOP, first because I'm not completely convinced that that's a good idea, and second because after 30+ years OOP has never really surpassed procedural programming, so how much chance does FP really have to become dominant in my lifetime? I do know that I don't want to be some old guy that just can't get the newer functional programming style because I'm stuck in OO -- just like the guys who simply cannot shake structured programming and still write COBOL in C#.