ADSD, NServiceBus and Nuclear Armament – the full story!
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.



I would have loved it if Epiq couldn’t have flown me out to the course in Melbourne…..Anyway next best thing, we are working on approval to get Udi to run his course in house. (Just need to get the document reviewers out of our training room!).
[Reply]
@Heath that’s good to hear. Hope you can get it approved.
[Reply]
Simon, I did not attend a course but I would like to add my 5 cents:
IMHO It’s impossible to be expert in EACH technology, vendor trying to invent and reinvent (so you technology depth is LIMITED but should be efficient to deliver a REFERENCE architecture)- those are “known Known”
Technical breadth - it’s about vendor technologies that exist out there but you only aware familiar with them only by abbreviation. (Those are “known Unknown”)
And the rest are “unknown Unknown” - technologies are out there bit you are NOT AWARE of them whatsoever
I like this picture:
http://i065.radikal.ru/1003/f9/b7787d7b74d6.jpg
Cheers,
Igor Rozenberg
[Reply]
Igor
Completely agree it’s impossible to be expert in everything and I believe as strongly that it’s not generally useful to concentrate efforts on becoming an expert in any particular technology for the sake of attaining the status. My belief is that one should focus on trying to master the skills that enable better design skills and hence make better technology choices as a consequence. For example, I see a lot of people very single mindlessly running after the idea that becoming a WCF or WPF or WF Guru might in and of itself lend credence to the notion that they are somehow architecture / design experts. On the other end of the scale, it’s not frequent that developers ask ‘what design book or practice or methodologies should I learn’?
[Reply]