Living in the Tech Avalanche Generation

Hot on the heels of Udi’s visit to Melbourne this year (in January), comes another chance to make good if you missed out. Plans are underway for Udi to visit us yet again, this time in Sydney. If your interested check out Udi’s post and register your interest using the link for the proposed Sydney event. If you want to know more about the course you can see the course outline here and read my review which contains links to some further reviews from other attendees in Melbourne earlier this year.

After having recently sat through Udi’s 5 day course on Advanced Distributed  Systems Design (ADSD) and after several days of quiet introspection punctuated with some random reconnecting to the web full of it’s opinion and ideas, I found myself ever more at peace with the challenges that lie ahead. During a conversation with Udi whilst he was here in Melbourne recently, he recalled a twitter comment made by my colleague Mark wherein he quoted my flippant remark that having NServiceBus at my disposal could be likened to being armed with nuclear weapons. Perhaps it wasn’t the most elegant analogy but I think it conveys the sentiment, I feel able to leverage and harness a great deal energy and power. This sentiment can also be attributed to the many great ideas that you find yourself being exposed to in the ADSD course

In these times of rampant software development technology proliferation, it would be easy to feel overwhelmed and I know from speaking with colleagues that many do, yet somehow I feel more at peace than ever. Technology stacks, frameworks, buzzwords, paradigm shifts, they are all hurtling towards us at a pace most of us have never known and the inertia alone is staggering.

Many of us need help in separating the stuff from the fluff. As Neo said to the architect, “the question is choice”! Well, is it? What are the choices? Do technology choices alone get your system built? No of course they don’t but many have fallen into the trap of behaving as though they do. Ever caught yourself saying something like “oh if I just use MVVM or ASP.NET MVC, my system will be perfect because of benefits X, Y and Z”? Other developers occasionally ask me, “what technology should I learn next” or “how do I future proof myself”? I think they are somewhat surprised by my answer; my advice is to stay as far away as possible from attempting to build value as a vendor stack expert and focus attention on maturing and refining your design and communication skills. It seems obvious really, after all once you have well developed your design and architectural skills, then you are far better placed to make appropriate technology choices. The ensuing  implementation experience will sort out any technology knowledge gaps that you feel the job’s market is causing you to feel downward pressure from. This doesn’t mean ignore technology all together, by all means pull it apart and analyze it, see how it fits but not in isolation – you need to give it it’s context. This became quite plain to me after having been through the course two years ago.

The DDD / SOA course was a lynch pin for me it was the key that has opened many doors. Without the learning in principles first, no technology will stop you from making a mess of things. Again it’s pretty obvious when you say it but I am sure I am not alone as someone who came to the course with a whole set of assumptions based on layered designs and technology fads as a bag of best practice tools and tricks.

I have now had the privilege of sitting this course three times and it never get’s old. Since I first experienced it two years ago, the content has changed a little and become even more refined. Each time I sit through the course I feel more empowered than the last time, the lessons are learned more deeply and start to become part of my psyche.

Some of my fellow attendees have posted their thoughts upon having completed the course just recently in Melbourne and I suggest you consider their feedback as well. If you haven’t heard there is now a mailing list dedicated to discussing the courses content and if you are planning on attending in London or the US sometime this year you should definitely check out the mailing list.

I would like to leave you with this; if you have not done this course and you have even the vaguest inkling that you might stand to gain something from learning what what some of the best architects in world know but rarely share in great detail, then do whatever it takes to get yourself a seat when next ADSD rolls into town or find a way of bringing Udi and the course to you.

As a an avid NServiceBus admirer my curiosity about the testability of Workflows in .NET 4.0 led me to ask the question in a group setting recently. One of the responses was “why would you want to test a workflow”? The respondent continued with “surely you would only unit test the components leveraged inside a workflow”? I have to disagree with this assertion! I do want to test my workflows because of reasons such as:

• I’d like to know if a given message types and content cause my workflow to behave exactly as I expect.
  • Did my order submission publish a message to any other endpoints interested in the state of the order submissions outcome?
• If the current state of my workflow is about to be de-hydrated, what are my expectations after handling a given message, were the subsequent expected events raised and or messages sent?

These kinds of concerns when dealing with long running processes in my services really do matter – the business requires such co-ordination to work or fail as described by specification and business workflows inherently contain testable logic - think of your average state machine or consider SLA’s where a de-hydrated (persisted) workflow has passed an acceptable time boundary, raising events commensurate with that business condition. Sure I need to test my business components too but the story is bigger than that!

NServiceBus Sagas are probably the closest correlation to a workflow in the WF stack and Sagas are eminently testable with a baked in testing API designed for the purpose. I guess it’s time to check what WF 4.0 has to offer and see what the story is for myself. More on that a bit later.