Once bitten, twice shy.

Maybe we should put up a logo with those wind-up teeth biting down on the letters YAGNI.

I don’t have anything useful to add; I just wanted to see those words again. More people need to say them.

A few weeks ago 37signals had an outage when all their single-data-center redundancy failed. I was perversely happy, because now they’ll know they ARE gonna need it, and they’ll probably end up doing something brilliant in Rails core because of it. If not this time, because it’s a fluke, then next time, when it becomes a pattern.

Sometimes you just have to get bitten.

Great to hear from another “old-school” developer.

If I see something that doesn’t build upon the wisdom that’s been distilled over the history of software development, I’m pretty skeptical.

It’s one of the things that sometimes drives me mad about the YAGNI philosophy of Agile. We need to stop throwing out the baby with the bath water.

You’re correct that I have not implemented the ReceiveMessageLater method on the GenericWcfTransport – it is something that requires doing some internal WCF black magic. The reason for that is that in WCF the bindings do so much that it is near impossible to give a single implementation that will be correct for all bindings – believe me, I’ve tried (and asked for help).

The MSMQ Transport is currently the transport that is production ready.

I’ve been thinking of ways to separate out the different implementations of the various interfaces to make that more explicit.

Any ideas?

“This is plain Separation-of-Concerns”

That is the key to the whole picture. Where tons of folks get in trouble is not building software with a clear understanding of and execution plan for addressing Separation of Concerns. Then, weeks, months, or even years down the road, they find themselves needing to do a complete rewrite to address a deficiency in the scalability of the system (or any of a number of functional changes), where they could have simply rewritten a small module that was hidden behind an interface. And to add to the mess, they can’t separate in their heads the concepts of scalable design from the concepts of Separation of Concerns, as they see those as such a deviation from how they currently create software, that each are equally scary. Yes, that’s a simple view of the world, but IMHO, it’s as close to the truth as I’ve seen.

However nservicebus does not seems to be production ready (or even prototype ready) regarding the WCF generic Transport. For instance, when trying to configure the test application with WCF transport(either BasicHTTP, NetTcp or WS Dual binding) it fails on the ReceiveMessageLater method (NotImplementedException()) just after starting the bus.