After all, ORM might really be the Vietnam of Computer Sience ...

The best DSL I've ever seen for working with data is SQL.

- Rob Conery, Thoughts on WebMatrix

The last mile is what kills object-relational mapping. Rails ActiveRecord does not try to go the last mile.

- Paul Wilson,
The Vietnam of Test Driven Development

Abstracting SQL often isn't a good idea from my experience

- @codemonkeyism on twitter

I have a high opinion of StackOverflow. What they accomplished in a very short time is amazing.

Reading the news that StackOverflow is writing its own object-relational mapper made me think ...

As a consultant I have seen almost no project that did not run into troubles with their ORM infrastructure at some point in time ...
... so maybe Ted Neward was right when he claimed that ORM is the Vietnam of Computer Science more than five years ago.

I cannot make my mind up on this one...

On one hand, I am a big fan of ORM. I am regularly teaching JPA.
On the other hand, I am tearing my hair out, again and again, fighting with ORM frameworks, trying to persuade them to do what I actually want (usually having a very clear idea what I want but having to shave yaks to get there, while in most specific cases it would be easy to just write the SQL I want).

Maybe it is the ORM frameworks that are the problem?

For advanced usage scenarios it often feels like ORM frameworks are adding a lot of accidental complexity.
But then again, I think ORM itself represents an essential complexity that always surfaces one way or another... sooner or later ...

The ORM-Vietnam-Hypothesis talks about quick initial successes and the Law of Diminishing Return.

Now here are some interesting questions:

• How valuable are the initial successes?
• How long lasts the phase of initial successes?
• How can you prolong this phase?
• How can you reliably detect that the law of diminishing return kicks in?

Is it possible to somehow leverage the phase of initial successes and then stop at the right moment and turn to a better solution without loosing all the initial sucesses?

Is that what StackOverflow is doing, turning away from Linq2Sql now, going for a custom ORM solution?

StackOverflow started in 2008 and has gone through an amazing evolution since.
They started with a very simple programming stack and very modest hardware, with only some part-time programmers (as far as I remember from the Hanselminutes podcast). Yet they were able to create a product that influenced the live of most modern programmers...
To achieve this, they had do choose the most pragmatic solutions. I guess Linq2Sql was the obvious choice ...

Would StackOverflow be better off if they started with their own ORM implementation from the bginning?
Probably not ... I guess they would be at the same point now: They would have to rewrite it today based on their real world requirements and their experience from the last 2 years.

It seems that this leads us back to the principle that Premature Optimization is the Root of all Evil...

Could this be a general advise: ORM frameworks being there to get you off the ground easily, but prepare for a rewrite later, at least for some parts of your application?
Don't invest too much in your ORM infrastructure, so that you can't turn your back on it once the Law of Diminishing Returns kicks in?

... and how to achieve this efficiently?

While I was writing this post Hanselminute 262 was published, interviewing Sam Saffron and Rob Conery about their Micro-ORM implementations Dapper and Massive.
Interesting ... Micro-ORMs as the shiny new thing between the overblown swiss-army-knife-style-ORM and the not-invented-here-do-it-yoursef-style-ORM?
The podcast also talks about the fact that a simple "in-line" style of writing apps with fewer abstractions is becoming stylish again ... right the style we condemned and tried to get away from 15 years ago... and how this is related with a modern "getting things done"-mentality ... very interesting indeed.

follow me on twitter, I need some friends :-)

Published: My podcast about Reactive Extensions for .NET (RX) with Bart De Smet

My interview with Bart De Smet about Reactive Extensions for .NET has been published last week.

You can download the podcast episode directly or you can can subscribe to our podcast feed in iTunes.

Reactive Extensions is a really interesting project from Microsoft for the .NET platform and also for JavaScript. It is a fresh approach to asynchronous and event-based programming. Looking at the concepts of Reactive Extensions definitely did broaden my horizon.

Bart De Smet is a very interesting guest.
He is actively involved in the design and implementation of Reactive Extensions.
I liked his theoretical approach to the topic of reactive programming and his ability to explain complex things in a simple way.

And the coolest thing about him: He titels himself “Functional Programming Geek” on his Microsoft business card!

TechTalk Event: What can you develop in 24 hours?

On April 14th my co-worker Thomas will hold a very promising presentation about Rapid Application Development with modern development tools.
He will present the findings from a daring experiment:

"One application, three platforms, 24 hours: Mission Impossible"

They took an existing ASP.NET MVC 3 application and wanted to find out how much of the given functionality can be re-implemented in 24 hours with the following platforms:

• Microsoft Visual Studio LightSwitch
• Ruby On Rails

Sounds like an epic battle: Rails vs. LightSwitch? If this does not have the potential for an endless flamewar, I dont know what has?
Everybody is welcome, including zealous Rails fanatics and corporate CTU agents ...
The event will be presented in German.
Date: 13.04.2011
Time: 16:30 - 18:00 Uhr, afterwards Apéro und Fingerfood
Where: Technopark Zürich, Technoparkstrasse 1, 8005 Zürich
Register online, the event is free!

Update 2011-04-24: The presentation is available online on vimeo (in german)

follow me on twitter, I need some friends :-)

Interesting: Continuous Integration vs. Feature Branches

In this interview Martin Fowler advises against using Feature Branches, since it is incompatible with Continuous Integration:

So we very much follow the principles of continuous integration, which is not something you can do at the same time as feature branching.

- Martin Fowler

Fowler advises to use Feature Toggles instead of Feature Branches for the development of features that takes longer than a release cycle or features that the business does not want to have released yet.

I should also point out as well I do advocate using feature toggles for features that take more than a release to implement, but it’s only the second best solution in that case. The best solution is to find a way to release the feature’s capabilities incrementally and usually you can do that and people need encouragement to go down that path. And only when you can’t and absolutely can’t should you use toggles.

- Martin Fowler

These are interesting concepts and I wonder if they are equally valid for all kind of projects?
I think this advice is mainly aimed for projects with a compact, dedicated team with clear goals that is aiming at striding forward at a sustainable pace.

In open-source on the other hand, I see a flourishing ecosystem of projects where people are working together in a more loosely coupled way. "Social coding" on GitHub is the best example here, where forking and submitting patches is made ridiculously easy.
Here I see the concept of feature branches as a very sensible concept...

follow me on twitter, I need some friends :-)

Speaking at the Norwegian Developers Conference 2011

Gaspar and I were invited to the Norwegian Developers Conference.

We will hold two sessions:

• SpecFlow: Pragmatic BDD for .NET
  (hopefully with a guest appearance by Dale of Mono fame)
• Building .NET applications with BDD

Thanks to Jonas Fellesø and Jakob Bradford for inviting us!

The agenda of this conference is crazy! It is a great honor to speak among so many masterminds of our industry.

follow me on twitter, I need some friends :-)

Tidbits: Microsoft Platform vs. Startups

StackOverflow and TekPub were my prime examples for cool sites based on the Microsoft stack. It seems that I have to look for new examples:

We put a lot of thought into this - MS stack doesn't scale for startups.

- Rob Conery, Founder of TekPub

Stack Overflow was known for their Windows stack, now they are using a lot more Linux machines...

- Stack Overflow Architecture Update

follow me on twitter, I need some friends :-)

Continuous Delivery, the next big thing?

The cloud is more than just scale, it is also effortless deployment.

- Scott Hanselman, Hanselminutes 255

Kent Beck is talking about Continuous Delivery in Software Engineering Radio 167:

[In software engineering] the big trend is towards more frequent deployment. And that drives everything else: All the social changes that need to happen, the technical changes that need to happen. The changes in practice, languages, and infrastructure ... If you are deploying 50 times a day [...] the current separation between ops and dev has to go away ... Marketing, sales, business models: everything changes when you are deploying very frequently.

Here are two real world examples of continuos delivery:
First check out code.flickr.com, scroll to the bottom of the page. You should see something like:

Wow impressive!

Then check out the presentation Continuous Deployment to Production 50 Times a Day on InfoQ.
According to that presentation, the applications at wealthfront.com get deployed to productions 50 times a day (with peaks of 100 times a day). They have a sophisticated deployment pipeline with automated self-checking and self-rollback of their different production services.

Want to jump on the bandwagon? Get your copy of Continuous Delivery.

follow me on twitter, I need some friends :-)

Update 2011-11-13: According to this presentation by Zach Holman GitHub deploys 10-40 times a day.