I sat down yesterday for a really interesting interview with a potential client. We discussed a variety of things, but one thing that stood out for me was a question around which message bus I would use and why.

Apparently there had been some discussions already, and the application being developed might need one in future. So the team had been discussing their options, after all at some point in the future the whole organisation could benefit from this and other applications could start to use this message bus to benefit everyone.

My response, and a rather unexpected one it seems, was “do you really need it?”, and “if so, what’s wrong with just using MSMQ?”

I’m all for simplicity, and YAGNI, which this decision would fall firmly under – but I’m also a great advocate of:

Delay All Your Decisions Until The Last Possible Moment

Although the team could have gone for a well established message bus, JBoss and RabbitMQ were mentioned as options – my view was that this was a decision they didn’t need to make now, and making that decision could possibly work to the detriment of this project, and possibly of the whole organisation.

While this project may well need a messaging system of some kind, the implications of picking one of these choices, or another like NServiceBus or MassTransit now were quite large.

Without any requirement from the organisation as a whole, picking a message bus and hoping the rest of the organisation would run with it too were small – something intended to work on this scale requires a lot more time, thought and consideration than was available, and putting it out for discussion at this point could delay the current project, potentially fatally.

Picking one of the options now for this project in isolation was a much better route, but the requirements for this application are as of yet unknown, and so any choice would be made on an arbitrary criteria, potentially going down a technology route for the sake of it, rather than a real need. And the more complex the solution picked for this application, the less likely it was going to fit with the organisation’s wider decision later on.

So my answer was simple … for now I would go with a very simple event broker in the application, and have that use the simplest possible method of messaging available right now (probably MSMQ). When the needs of the application developed, it would then be simple to bring in a more advanced bus system by just changing the event broker, or similarly if the organisation’s needs became clearer it would be easy to use their bus of choice.

This was a decision that didn’t need to be made at this point. Consider it a premature optimisation.

By taking a simple option now, and delaying the real decision to a later date, the team will gain flexibility on their immediate application, gain clarification of their requirements and of the organisation’s requirements as a whole, will avoid locking in to any technology that could be harder to back out of later – and most importantly of all – keep focused on delivering the project at hand, rather than get distracted by this decision.

When a decision stops being trivial, delay it until the last possible moment you can – you will always have more information by then, and will therefore make a better decision.