the ‘bee log

Oren’s got a post up talking about when he chooses to build a framework. There’s a lot of pushback on frameworks in the agile community. Try it the next time you’re around a bunch of agilistas; it’s a great way to “stir the pot.” Depending on the day or phase of moon I’ll either take the side of framework or not. How I do love a good argument and when no one will be the provocateur I’ll happily volunteer…

Let me be clear. A lot of agile folks evangelize and utilize frameworks to great advantage (NHibernate, Rhino Mocks, Ruby on Rails). The “hate” part tends to come from more of a “framework as a route to your application” angle. That is, building your application by building a framework or setting up a framework/application team is a bad, bad, bad idea because it’s BDUF, encourages YAGNI, and keeps the team from delivering value to the customer. I’m an agile proponent and, generally speaking, I agree to an extent.

Lately there’s been a lot of bile directed toward the CAB/SCSF project from Microsoft patterns & practices in this corner of the ’sphere. Having gone out and done a few talks to developer groups / code campers on the very subject I have to say the hate really isn’t warranted. Sure you can build your own CAB. We started down the CAB/SCSF route and are now in the process of replacing it. Right from the get-go I didn’t like the state bag stuff.

So is CAB/SCSF without value? No, absolutely not. It opened a lot of people to the concepts of dependency injection, composite applications, pub-sub eventing, and a host of other patterns. In that it has value. It also has value in terms of the big IT shop in that it proscribed a way to separate the concerns of development: layout/UI, business logic, etc.

The other thing to remember is you don’t have to use this stuff as is. A lot of this p&p stuff doesn’t need to be taken at face value. It’s valuable as a reference architecture. Take a look. Take what you like. Leave what you don’t. See how they’ve assembled patterns together. If you think you can do it better/lighter, by all means, rock it. There’s value in disagreement especially when it helps to clarify your position.

All this said, I think there are times when a build-a-framework approach is warranted. Specifically if you’re building a product and you’re able to isolate a class of feature-types that you’re likely to build over and over again it can give you competitive advantage: an idea championed by Mark Miller in regards to product development:

if you are competing against another company, one of the ways that you can gain a competitive advantage is by making it faster and easier for you to extend your products and that’s just bottom line. [DNR Show #101]

This is a position I agree with. Keep in mind, though, product development is a different animal. It’s harder (Frederick Brooks says by a factor of six times). That and “the customer” can and often is based on a thought experiment (marketing, instinct) at the very beginning and as you accumulate real, paying customers an aggregate measure of demand/interest/needs/requests over time. You, when you’re a product company, are the steward of the product; ultimately it’s up to the maker to meet their customer’s demands (and I think a more-or-less agile approach is an excellent strategy there), but that’s another post for another day…

A huge thanks to everyone who came to see my talks at the Central Penn .NET User Group and the Philly.NET CodeCamp. I had a great time and it was well worth the haul out of the city on both occasions. I wonder, though, when I will learn that yellow cabs are not a universally available service.

Download the code for my DDD/NHibernate talk here. Note, you’ll need to go into the App.config of the unit test project and update the connection.connection_string to something relevant for you. Then you’ll want to run the CreateDatabase.DoIt test having been sure to uncomment the [Ignore] attribute.

I also uploaded a zip archive containing the projects I used in my Validation Application Block and Policy Injection Application Block talks. Get it here. Note: you’ll need to download Enterprise Library 3 to run these samples.

If you can’t tell I’m catching up on Udi’s blog. He’s got a post up with some commentary about Martin Fowler’s “Anemic Domain Model Anti-Pattern” and it’s typically insightful so read it.

If Domain-Driven Design taught me anything it’s that Domain Model isn’t a pattern in itself; it is a Pattern Language. This is an “aha moment” I first had at my DDD talk at the CodeCamp NYC. It actually occured to me while I was giving the talk and it’s just now resurfacing again in my consciousness. So, as I like to proactively avoid those Howard Hughs moments, I’ll get it all out now.

A Pattern Language is a network of related patterns that apply to a single vertical or horizontal domain of variable size. They’re described as networks because patterns bare association and compliment other patterns in the same language. This can be seen in DDD, for example, in the connection between Entities, Factories, and Repositories. A pattern language usually .

Of course, domain model is be well expressed with the patterns in the Evans book but it works quite well in conjunction with the classic, GoF design patterns, etc. In this sense I’d say that DDD is a subset pattern language of the larger Domain Model pattern.

Domain Model also encompases patterns beyond what we think of as “software design patterns,” those little static structure diagrams and problem/context/forces/1000-words-or-less (generally) descriptions. Choosing Domain Model and doing it effectively means adopting a variety of principles or, what I like to call, Work Patterns. These are the kinds of important principles often talked about such as OCP, SRP, Demeter, Polymorphism, Encapsulation etc.

The Domain Model Pattern Language doesn’t stop at knowledge of principles or best practice it can go into larger methods such as TDD, BDD, Mocking, and Refactoring. More often than not these Work Patterns are habits that come from practice and manifest themselves in your code as “doing the right thing” and making “good choices.”

If this post had a point, it’s only to share the idea that Domain Model is a big, big thing. It’s probably overkill in a lot of cases where you have simple applications that have very simple purposes. If you’ve got a complex application/domain — especially one that’s going to live a long time (and don’t they all) – it’s a great choice. You gotta build these things from scratch, friends, and there’s no ActiveRecord/SubSonic safety net that’s going to do it for you. You should, however, know that when you choose Domain Model and plan on getting it right, you’re committing to a rich and integrated lifestyle.

Udi Dahan has a post up commenting on the Astoria project coming out of the ADO.NET team in which he entreats, “please, Microsoft, just stop.”

I have to say that I feel absolutely the opposite way. I see Astoria is a step in the right direction. That’s not to say I’m any kind of acolyte of the REST/SOAP wars or even that I think Astoria proscribes a better way to do data access. All I’m saying is that it’s nice to see alternatives.

Is Astoria going to be useful in my present scenario? Probably not. When you add authorship and metadata and a few other key services to the mix will it make a sweet service for lo-fi, quick and dirty mashup’s? I sure think so.

Another benefit of Astoria is that it dogfoods the “service builder” aspects of the Entity Framework. I think this approach to experiencing the development, well, experience is bound to have positive effects when/if EF becomes available. Who knows they may find ways to improve the API, code, etc.

One of my complaints about Microsoft has always been the fairly monolithic approach to guidance, tools, etc. I like what I’m seeing now; variety is the spice of life.

Jeremy is right, I didn’t anticipate the level of reaction on my ALT.NET post. I think this is a common experience in the blogosphere. You end up putting a lot of stuff out there that you pour lots of time into and they do mediocre. The thing you just fire off in 15 minutes is what ends up stimulating the most conversation. By-and-large I was surprised people latched on to the idea because there’s not much really new there other than a bit of a pithy name and a summarization. Recall my post starts as a reaction to Scott Bellware’s post and he’s been ranting about this stuff for a long time.  

By “ALT” I really didn’t mean “you’ve gotta be a cool kid.” I understand, though, the “ALT” part has that cachet. I know I personally think that all these people walking around me in the East Village wearing skinny jeans and rocking fashion mullets look like assholes. Largely I have the same reaction to similar fashions in the software world. At least those that work in a way similar to fashion being pushed by companies and mainstream media. My meaning was less about fashion and more about ripping out the vendor-supplied feeding tube. Let’s get back to practice and technique folks.

Sure lots of the stuff ALTernative to business as usual is “so 1994” or “so 1979” but it doesn’t change the fact that there are ideas we should be incorporating right now and, for the loud mouthed, write about, experience, encourage and promote. No matter how old an idea it’s usually new to someone…

Jeremy might not be a Pearl Jam fan, but they’ve got a song describes the when-utility-becomes-empty-style phenomenon: “Corduroy.” I bought and wear this (Corduroy) jacket because it’s comfortable, warm, has lots of pockets and I could afford it and now that I’m a hit you can buy a replica at Barney’s for $1200. Let’s think about Eddie Vedder for awhile. Sure he’s one of the founding voices of the “grunge movement,” what was it about Pearl Jam that was ground breaking? Really you’ve got shades of Jim Morrison in that voice mashed up with a self-identified homage to Neil Young in the melody and song-writing departments, yet he and the band are considered ground breaking.

That’s a good analogy for how new ground gets broken in software development. So much of what we adopt as new practice is either a composite or incremental improvement on what’s come in the past. We wouldn’t have BDD without TDD. We wouldn’t have TDD without the idea of Unit Tests. Ideas beget ideas and it’s the community or the act of shopping things around and dogfooding your theories against the experience and thoughts of others that makes things surface, gain traction, and improve the world order. Again I can take it back to the grunge metaphor. Pearl Jam got attention partially because of Nirvana, Soundgarden, etc. In development and music alike it takes a village.

I could expand on the comparison lots more – Pearl Jam is to NUnit as Creed is to MS Test — but I’ll stop here for the time being.

Like Ayende, I also didn’t anticipate people would jump right to the focus on tools, especially considering the bolded “it’s not about tools” part. That and partly what I’m saying is that healthy tension and a measure of dissatisfaction is what it’s all about: if we all become fat on what we’ve had, the ways of old, and what we’re being fed, well, that’s not good. I constantly want to bring new juice and ideas into the mix. It’s a big part of what attracts me to this business. 

Oh well, people hear/read what they want to hear/read. We, as developers, always talk about “capturing intent.” I thought the post was relatively succinct and fairly well-crafted, but here you have an example in the wild of how capturing intent is difficult in the English language, never mind “made-up” programming languages with extremely limited vocabularies. That said I think some of the reactions were relevant if you take them as instances of a class or personal testimonial.

Asparagus, Brocolli, Cauliflower…
Dandelion Greens, and Escarole!
Fennel, Grapes, Honey Dew Mellon…
And Iceberg Lettuce for the Salad Bowl!

Before you start thinking “Jesus, Dave has lost his mind” I should tell you that this is part of a song from a high school play I acted in, Plain and Fancy. I played an Amish fellow named Jacob Yoder and had to wear a fat suit. I had a total of four lines.

Seriously though, for me, May is all about taking the stage in the Keystone state!

On May 15th I’ll be doing two talks at the Central Penn .NET Users Group. First we’ll cruise through the Validation Block in EntLib3. It’s a half-hour talk, so by “cruise” I really mean “drive by” in the Compton sense of the phrase. Following a quick pizza/caffeine refuel we’ll be digging into my NHibernate/DDD talk. Get the details over here.

The following Saturday, May 19th, we’ll be pushing models like weight with my DDD talk (it’s a big topic so even if you see it at Central Penn, no worries, there’s a lot of takeaways) at the Philly.NET CodeCamp. I’ve got another slot where I was planning on digging into the Policy Injection and Validation Blocks in EntLib3, but coming off of MIX07 I’m thinking of possibly, well, mixing that up. More information lives here, but, if you haven’t registered already, sorry pal, it’s all sold out.

Of course, a couple of things will have changed since my high school acting days: a) I’ll have a lot more than four lines of dialog and b) I won’t being wearing a fat suit this time. You should know, too, at both engagements I promise to be quite a bit less weird than this post makes me seem.

Just came from the talk with John Lam and Jim Hugunin. Wild talk. They had, with the DLR in Silverlight, several languages mixed in a single application. What strikes me as interesting is the shear power you’ll have with the DLR in cut-n-code prototyping work; you can grab an existing 3D engine in JavaScript and mash it up with your Ruby code that handles an HTML button click from the hosting page, etc. The possibilities and combinations are staggering…

The demo code including a nifty “try it out” / IRB-style console is available at CodePlex, right here.

Fact: The DLR can be hosted outside of Silverlight. I suspected but this is the first time I heard this explicitly. In retrospect it makes sense as IronPython runs all over the place. Allegedly there was a demo earlier (didn’t see it) that demonstrated running dynamic languages in an ASP.NET application.

The performance is quite amazing for languages running on the DLR. For example, IronPython’s performance already exceeds that of the ”official” Python implementation. I wonder if this is the solution to Rails performance issues… assuming, of course, you can/will swallow the licensing pill.

The Ruby implementation isn’t 100%. It’s coming, the check’s in the mail.