The Freak Parade

I’m having trouble sleeping this evening, so I thought I’d try to pacify my mind with a little midnight rambling. I’m probably in pretty good company right about now – I recently saw on a Discovery channel program that a ridiculously high proportion of Americans have a sleeping disorder of some kind, primarily some form of chronic insomnia. That jives with my general experience. Most adults I know have trouble sleeping at least a few nights a week.

I don’t think the reason for this phenomenon is any great mystery – as our culture continues to accelerate and radiate increasing quantities of noise (in the form of information and technology driven social interactions), our minds become exponentially busier in order to keep up, yet our lifestyles don’t often permit sufficient time to “decompress”  so we have trouble sleeping. Our minds simply can’t stop twitching when we turn off the lights and close our eyes.

If you have any doubt that the pace of change is accelerating in our society, watch this. Actually, watch it anyway, it is a fascinating presentation. Our natural tendency, when we reflect on our rapidly changing culture, is to judge it as either robbing us of our souls or as the righteous march of human progress. In reality, however, whether or not this change is good or bad is a meaningless question. Nothing can hinder or contribute to the phenomenon by some application of our will, such change is outside the realm of human control.

Even so, just because we can’t alter the onslaught of cultural entropy doesn’t mean we have to be utterly swept away by it, simply accepting as inevitable fact that we’ll be sleeping less and less year after year.

The video I just referenced asks this question at its conclusion: “What does it all mean?” This question, of course, is not a question, but the Question. Christian mythology holds that Man fell from grace when Eve ate from the fruit of knowledge and thus launched all of human history. The fruit of knowledge needed only to transmit to mankind that single Question to have its effect. It isn’t an opposable thumb or the ability to make tools that defines and sets our species apart from the rest of the animal kingdom, it is that Question, the relentless pursuit of which has given birth to the entirety of human culture. Furthermore, our inability to answer that Question accounts for our uniquely human suffering – the widening spiritual hole in our experience of life that our consumerist culture is scrambling harder and harder to fill, by way of technology and mass production. This is perfectly captured in this cartoon:

As a side note, I highly recommend subscribing to the Noise to Signal RSS feed – a desperately needed dose of perspective in the form of very funny cartoons. Anyway, my intention is not to be critical of our culture, but simply to consider it in order to aware of it so as to find a way to live in it without being utterly enslaved by it. I believe this is critical, because while the acceleration of our culture may be inevitable, it is accelerating towards increasingly unsatisfying ways of approaching our thirst for meaning.

My belief is that the answer to the question “What does it all mean?” is the question itself - “it” means to be aware of the utterly un-resolvable mystery that is human experience, and to explore and study this mystery as long as we live. Our culture is fundamentally unsatisfying (from a spiritual perspective) because it is oriented towards blindly trying to find a salve for some illusory spiritual wound, it does not approach the Question directly, and so it won’t ever have a chance at answering it, or of quenching our thirst. Of course as any Zen Buddhist will tell you the Question is a trick question to begin with – it is the metaphysical phrasing of the joke “Who is buried in Grant’s tomb?” – Grant of course. “What does it all mean?” – it means itself. The goal of a Zen student’s practice is to “get the joke” – not intellectually, which is trivial, but viscerally, experientially, which is not so trivial. Anyway, for those of us who are not Zen students, that doesn’t help much. Even so, I urge you to not forget about the mystery – if we lose the context of the Mystery, or the Question, then our accelerating culture will eventually eat us alive or at least wear us down, but as long as we remain aware of the Mystery and the Question, and attend to them both on a regular basis, then any pace of change or mutation of our culture will be both endurable and enjoyable. Of course, this is easier said than done, which is why I’m up at three in the morning philosophizing instead of sleeping peacefully next to my wife

The pace of change in the business world is accelerating at a rather alarming rate, as you may have noticed. The mighty Internet is compressing time, geographical distance and even our attention spans with ruthless disregard for our spiritual well being. As the pace of change increases the ability of any given organization to navigate skillfully in such frantic waters won’t remain a mere competitive advantage but will soon become a matter of survival, if it isn’t already.

Gone are the days of blissfully sailing across the open sea gleefully screaming "Fire!" one minute and hitting the deck the next as your competitor’s logo-imprinted cannon balls whiz overhead. We must continue the battle,  of course, but the open sea has been replaced by the thin edge of an epic vortex that keeps growing larger, spinning faster. When everyone is always talking about increasing "Business Agility," whether it be through implementing a well-governed SOA or by calling upon the power of Satan, what they are really talking about is finding some way to keep from sliding down the side of the whirlpool and into the gaping maw of a giant squid.

Melodrama and nautical fantasy aside, the operating environment of the modern business is changing. Businesses are becoming increasingly sensitive to their environments as "Business Intelligence" - the buzz word that refers to actually making some use of the torrents of data flowing through our IT systems - begins to permeate our organizations.

Originally Business Intelligence (transactional data processed and presented for analysis) was employed primarily at the executive level to allow decision makers to analyze the past in order to make predictions (and therefore decisions) about the future. The current trend, however, is to push this kind of processed, aggregated and integrated data deeper and deeper into the organization, sometimes right down the the line level worker. This is being called "Operational Business Intelligence." Operational Business Intelligence is not at all strategic - it is intended to provide fast, objective feedback to operational units in order to improve real time or near real time decision making. Well, this kind of business intelligence isn’t your granddaddy’s business intelligence - it’s value is derived directly from its immediacy, its freshness and its narrow relevance. It isn’t a map for the Generals to study while they sip whiskey and play with plastic figurines. Rather, it is the static filled screams of "OH MY GOD THEY’RE COMING THROUGH THE FUCKING WIRE - I NEED AIR COVER NOW!" bellowing from the field lieutenants radio. It does little good to see such data on a report a day or two (or even an hour or two in some cases) after it is generated. This kind of data shouldn’t even be called analytics; it is direct feedback from living business processes and the good old fashioned ETL based nightly batch process that does some pretty math and coarse grained aggregations and takes forever to process just doesn’t cut the mustard. That kind of business intelligence it is too general and too damned old to be useful for making in the moment operational decisions.

Business Activity Monitoring (BAM) to the rescue! The acronym and the term were invented by some highfalutin Gartner analysts awhile back ago and refer to business intelligence systems which aggregate, correlate, and report (usually via live dashboards and other more immediate alert mechanisms) real time or near real time business data as it is generated by the transactional systems that run the business. Additionally, BAM systems will often employ a rules engine to detect actionable scenarios in the incoming event feeds and either initiate an automated response to such scenarios or alert an appropriate human who can take some appropriate action.

As you can probably imagine, the architecture and design of a BAM system must be dramatically different from that of a batch based, ETL powered system. Furthermore, simply populating the data warehouse isn’t enough - BAM systems deal with real time business events and data feeds and therefore must be prepared to detect and act upon (even if simply via some kind of alert or dashboard dashboard alarm) various business conditions. This kind of task is something data warehouses are ill equipped to address.

Rather than processing data at some interval, BAM solutions monitor business events and aggregate, process and act on those events as they are occurring. This style of processing lends itself almost perfectly to an Event Driven Architecture, or EDA. In an EDA distributed systems communicate with each other indirectly by raising "events" whenever some interesting state change occurs in the domain. These events are usually just messages placed on a Message Bus, or ESB, to which any other system also connected to the message bus can subscribe. At any given time, there may be hundreds or thousands or millions of "business events" flowing through an organizations message bus, providing a perfect opportunity for a BAM system to tap in and do its groovy business.

An Event Driven Architecture or Message Bus are not strictly required for a BAM system to work. BizTalk, for example, provides a BAM API which it expects LOB systems (or BizTalk orchestrations) to call into at various stages of processing to directly inform the core BizTalk BAM database of any interesting business activity. Somewhat more robustly, some of the enterprise BAM solutions provide a wide array of adapters that can allow transactional systems to publish events directly to the BAM software. I don’t think it would be fair to call this kind of arrangement an Event Driven Architecture; even though events are being piped directly out of transactional systems and into the BAM system, the event notifications are essentially a private conversation between each transactional system and the BAM system.

Even so, just because you can have BAM without an EDA and an EDA without BAM, the two technologies (or architectures) are perfectly suited for one another. BAM provides a layer of intelligence and analysis over real time business events, and an EDA provides a conduit for transactional systems to publish their business events to the broader enterprise in blissful ignorance of who else may be watching, including the BAM system. An EDA also provides a completely natural way for the BAM system to distribute information or initiate action when it detects the need to do so - it can just raise its own derived events, to which a dashboard, human notification system, etc. can happily subscribe. Put the two together and BAM! You have a closed feedback loop that will enable your operational managers and line level decision makers to successfully keep your Ship of Commerce out of the tentacles of a giant squid, and maybe even sink a few enemy galleons along the way.

Well, all this is just fascinating stuff, but if you aren’t a big enterprisey company with deep pockets, you will be pretty disappointed when you get to the BAM store with your fist full of change and your head full of high hopes. Most of the existing BAM vendors have been swallowed up by the infrastructure giants like IBM, Progress Software (Sonic ESB) and the like. Probably top notch solutions, but I wouldn’t know because I work for an SMB. Their salespeople generally won’t even acknowledge that companies like ours exist. The one free standing BAM vendor I could find, Systar, also prefers to sell to the big fish, or, as their "business development" guy put it, "Tier 1 Companies who pay licensing fees that start at a quarter of a million dollars". I’m not 100% sure what a Tier 1 company is, but based on the fact that he tried to convince me we didn’t really need a BAM solution, I’m guessing we’re not one of them :)  So, as usual, that leaves us SMB’s alone at the bar sitting next to a Microsoft solution, in this case BizTalk, trying to decide if we should just head home alone and take care of business ourselves, or down a few more shots of Tequila, heave a deep, forlorn sigh of resignation, turn to BizTalk and say "How you doin’?"

I should have more to say about that soon as we’ll be implementing a BAM/EDA solution over the next few months. Will a bag-over-its-head be enough to stomach an ongoing relationship with the BizTalk BAM product, or will we be able to stitch something together from open source tools and good old fashioned grit, piss and vinegar? Only The Shadow knows…

So this crazy metaphysical debate about how or why you (or your team) should learn TDD rages on, reaching a fevered philosophical pitch. There is a heavy drumbeat coming out of the ALT.NET encampment that is becoming increasingly difficult to ignore, and we’re finding ourselves torn on how to react. Do we have a moral imperative to march along? Is it enough to tap our feet under our desks and keep doing business as usual? Or should we tear off our clothes, paint our faces with the ALT.NET war paint, and take our place by the campfire? Ian Cooper recently pointed out that what is at question here is not TDD but the imperative for us, as an industry, to accept change as a fundamental aspect of our practice.

Change is nothing new. In fact, change is all there is. We all attempt to resist it in one way or another, but it is a useless effort, like trying to stand still in a rushing river. There is no such thing as "resisting" change - the best you can do is to pretend it doesn’t exist, but you can’t stand still. Even though you may not alter your behavior, your environment will change around you and your relationship to your environment will change despite your stubbornness, it can’t be helped. Whether change is good or bad is a meaningless question, and the question of whether to accept it or ignore it isn’t really a question of "self improvement" but a question of how much you will enjoy your profession and your life.

So while the call to change coming from ALT.NET is extraordinarily valuable, the relentless emphasis on the tangible business results of some particular change, such as a guaranteed suite of regression rests resulting from a move to TDD, creates a limiting environment in which to accept it meaningfully and realize its full value. The only way to accept change is to experience it with an open mind and feel its value for yourself. An emphasis on quantitative results is absolutely necessary for arousing interest in some new technique or methodology, but it should not be the only emphasis. Once interest is aroused the emphasis should immediately shift from the expected benefits which, at this stage only reinforces preconceptions and inhibits the learning process, to remaining observant, alert and curious about the actual experience and actual results the technique or methodology provide.

TDD is a perfect example because everybody is always talking about its objective benefits, such as a safety net for major refactorings, enabling collective code ownership, cleaner API’s resulting from testable API’s, but the real value of TDD is a complex mix of all of these things and more. You can listen with your jaw agape to  someone extolling its benefits for days at a time but until you actually start to practice it you can’t really have any understanding of it at all. This is true with everything, but with TDD the effect is very dramatic, and therefore very instructive. People are always saying "it’s about design, not testing" but then they go on to describe benefits that are often mostly about testing. This is because the design aspect of TDD is something you will feel when you try it with an open mind, it is extremely difficult to articulate. The results are not so hard to articulate, such as decreased coupling or increased isolation, but an understanding of why these benefits result from TDD is more visceral than intellectual.

People talk about learning curves as if they were impediments to obtaining the bountiful rewards of some shiny new methodology, but the learning curve is exactly what produces the rewards. The learning curve IS the primary value. The moment the learning curve flattens out is the moment you will find a new methodology to replace the old one. Ian said in his post that change results from the pain of a process outweighing our natural resistance to change, but I completely disagree. I believe change is the fundamental and most basic aspect of our professional lives, the very reason we enjoy what we do as much as we do, and that methodologies evolve not at the last possible moment when we can’t stand the agony any longer but at the first possible moment, the very moment we suspect our current practices cannot evolve any further. A work environment where nothing changes, where technologies are frozen at some arbitrary point in time and previously established development practices have taken on the aura of biblical law are most developers worst nightmare.

Yet, as Udi Dahan points out, we often feel we are not at liberty to go off experimenting with change at the expense of pressing business realities. And this is true to a large extent, and I agree with his conclusions - TDD or any other new process should be introduced into an environment responsibly, ensuring an appropriate level of safety for the business as well as the team, or the results could well end in disaster. The danger, though, is to use that as an excuse to avoid accepting change altogether. While it is suicide to ram some new methodology into the gears of a running machine, a more sinister form of suicide is to neglect change entirely because no time ever feels like the right time. Consciously and constantly adapting to change should be built into the foundation of your business culture and your development culture. This is the responsibility of the management and line level developers alike. If your company is not interested in continuously evolving along with the software industry and therefore does not provide a safe (if controlled) environment for experimenting with and adopting new technologies, practices and methodologies then you should find another job. Conversely if a developer on your team is not interested in adapting to change then you should transition them off your team, either out of the company or into a support role.

Finally, all this highlights for me the need to emphasize that business results are not why we come to work every day. You may like to believe that you invest yourself as deeply as you do in your career because you want to contribute to the success of your business, or provide the best possible experience for your users, or streamline business processes, and these things mean something, but you know and I know that those reasons aren’t the real reason you show up at your keyboard. You love your job because it is mysterious and fascinating and full of creative possibilities and interesting logical puzzles which give you immense pleasure to solve and explore. You love to create something out of nothing. Fortunately, this kind of enjoyment usually aligns, or can be made to align, quite well with business objectives. But the point is motivation - yes developers want to be efficient, yes developers want to deliver maximum business value, but even more than that they want to maximize their creative possibilities and they want to enjoy the time they spend in front of their computers. So if you want to sell TDD, Agile, IoC, or whatever it is, don’t forget to sell that aspect of things as well as the objective, tangible efficiency or quality gains.

My team recently attended an Open Space conference, Open Agile 2008, which is a sort of new age, ad-hoc, self organizing meeting of passionate people. An Open Space conference has a number of principals, but the one that really caught my attention was the commandment to "Be Prepared To Be Surprised." What is meant is this: put aside your pre-conceptions and expectations and expect to learn something new at any given moment, and in unexpected ways. This applies equally well to a new technology or methodology such as TDD: "You will come away with full test suites that will dramatically improve the quality of your software, your designs will have lower coupling and a cleaner API and fewer defects. Oh, and be prepared to be surprised."

Recently I’ve been doing most of my web browsing using Chrome, because it is new and fast and I generally don’t use a lot of plug-ins. Currently I have about 20 tabs open in the browser because I’m doing research on a few topics at once. Probably like most people, when I find some content I know I’ll want to read, I continue my further explorations in a new tab expecting to go through all the tabs later to read what I want to read or to catalog my findings using LaterLoop or Delicious. This works really well, except that every once in awhile something runs afoul in a particular web page and poof goes the browser. In IE 7, well, sucks to be me when that happens. My tabs were almost never restored. In FireFox 3 an unexpected crash did restore tabs upon reload, but the browser crashed a *lot* and starting a new instance and waiting for the tabs to load all at once is slow and rather painful. Worse, the web page that caused the crash would  be usually be marked for restore, so very often after a crash choosing to restore the previous session would result in a new crash, in an endless loop until I gave up on restoring the session or managed to get to the offending tab with a mad dash of my mouse and close it before it loaded the poisoned part of the page.

Well, those days of agony and uncertainty are gone with the introduction of "process-per-tab" browsing found in Chrome. I believe the newest version if IE will also support this model. Anyway, my computer suddenly slowed to a crawl, and task manager showed Chrome as the culprit. But not Chrome in general, just a tab in chrome. Actually, not a tab in chrome either, a window inside a tab in chrome that was hosting a flash animation, which had run amuck. Chrome actually has its own task manger, so the solution to my problem? Right click on the Chrome tool bar, choose task manager, look for excess processor usage, kill said process - and all is well. All 20 tabs breathed a collective sigh of relief, and I un-wet my pants and kissed my monitor. The damage? A portion of one of the web pages I had open showed a broken plugin graphic and a nice little notice at the top of the page said something like "A flash plug-in has crashed." A single tear rolled down my cheek for the poor, lonely flash animation I was forced to kill, but many more lives were saved. Thus is the price of progress.

A while ago I did a survey of some the CMS solutions available for the .NET platform. While there are currently a very large number of both commercial and open source CMS solutions available, the one that really caught my attention wasn’t available at the time for public review. Now it is not only available for download in either source or binary format, but is backed by what at first blush appears to be pretty extensive documentation via a dedicated wiki.

I’ll be taking a closer look at this over the next few weeks, but my general feeling is that this product will add tremendous value to the community, despite the many existing CMS products already available, and I am very excited to kick the tires.

Project Links

* Main Product Page: http://www.sensenet.hu/engine.aspx

* CodePlex site: http://www.codeplex.com/sensenet

* Documentation Wiki: http://wiki.sensenet.hu/index.php?title=Main_Page

* Discussion Forum: http://forum.sensenet.hu/

Sample Sites

Additionally, they have two case studies already of full blown, production sites built on their new system. The case studies give a brief overview of the projects and link to the live sites. Both of the case study web sites are Hungarian, though, so the experience is a bit awkward (unless you can read Hungarian, of course), but still gives you a flavor for the CMS. [Update] - the Invitel site has an English version here: english.invitel.hu

 Our team has recently embarked on the construction of a new application that is to be delivered using the SaaS model (hey, it’s what all the cool kids are doing.) As with nearly any modern software application, especially one delivered from the omnipotent Cloud, this new application must be able to integrate with systems and participate in process automations that are outside of its firewall. Additionally, because the model is SaaS, the application must be multi-tenant.

Strictly speaking, what we’re building is an almost feature for feature re-write of an existing application. However, the original app was written half a dozen years or so ago and even that effort was mostly just a port to ASP.NET from an even older classic ASP web site. My oh my how the computing environment has changed since then. Looking back it feels to me like the difference between putting together a model airplane and building an F-16.

Any line of business application being grown in the modern world that is expected to participate in modern process automations ends up being more like a bush or a tree than an n-layer cake. You can’t just bake the thing, slop on a little icing and throw it on the dinner table. It has to be grown in layers from a carefully considered seed and surgically grafted onto the living, thriving root system of an existing technological and human powered ecosystem.

I was rather taken aback, when I started to lay all this out in my mind, how many facets there are to building a “simple” business app in today’s day and age. To try and get some grasp on the big picture (which, thankfully, isn’t the most complicated big picture out there) I ended up mind mapping my understanding of your basic multi-tenant line of business app. It is a very rough sketch, and I intend to refine it as time goes on. Some of the nodes on the map have links to previous blog posts of mine or external resources, and I intend to add blog posts for many more of the items in this diagram as I get to those aspects of our own software. The next item on the agenda is Identity Management. If you have any suggestions, corrections or comments, I’d love to hear them. You can go to a full screen version of the mind map by clicking this link.

BTW - this was done using a combination of Mindjet Mind Manager and MindMeister.

Davy Brion recently posted about how he’s trying to ward off the fire-hose-in-your-face-while-you’re-trying-to-work effect of social media by replacing a large feed list with a (very) small set of link blogs. While that sounds nice in theory, and I can definitely relate to the urge to push the fire hose out of my face, I don’t think it would work for me as a turn-key solution. For one thing, the link blogs don’t cover all the bloggers I read, and for another I just hate to bank on the coincidence that one of the several .NET link bloggers will take a fancy to the same content I am interested in day in and day out. I routinely read posts in my reader that don’t end up in the link blogs.

One particular thing about link blogs, though, that generally doesn’t live up to direct subscriptions, is that the link blogs are usually just a long list of links - if I want a quick idea of what the post will be about, I need to click the link, which either takes me out of my reader and into the browser or changes the context of my feed reader from which I’ll have to back out to get back to the link list. If I get the feeds directly, I can read the first few sentences of the post directly in my reader and get an idea what the post is about, and if I should save it for later, read it right away, or let it slip on down the river.

Recently, though, I noticed my favorite link blog, Interesting Finds by Jason Haley, starting coming in two flavors - a “rough cut” version and a “final cut” version. The rough cut version is the usual long list of links. Then, a little later in the day, a “Final Cut” arrives - an attractively formatted subset of the rough cut with a short summary of the items! And pleasantly enough the items he chose to summarize were the ones that caused me to think to myself “hmm…wonder what that is about?”. Bravo! And I love that he’s publishing both versions, and not just switching to the final version only. Of course, it adds TWO points to the oppressive “unread item” count in my feed reader every day instead of one, but in this case it is well worth it. I’ll probably read the “final cut” first, only clicking on items I can now confidently be sure will interest me, and then skim over the “rough” cut very quickly, looking for things not covered in the final cut but that still might catch my interest.

I honestly can’t imagine how he has time to go to this kind of effort every single day, but I certainly do appreciate it, and I hope the two editions are a permanent feature of his blog as they more than double its value (at least for me).

So I had this blog post all ready to go about a common colloquial "accent" developing amongst bloggers in the .NET social media scene. It turned out to be a pretty stupid post by most standards, but even worse I found myself trying to be witty, which is a big red flag to <Ctrl-A>, <Delete> before I humiliate myself  beyond redemption and am forced to commit Hari Kari in front of my children, who I’d gather would be too horrified by the spectacle even to scream, and I don’t want to put them through something like that. No parent does. Even so I maintained the original title of the post as a keepsake of the words that got deleted; a lock of hair from a lover lost at sea.

Instead, as a tribute to my aborted attempt to be amusing and insightful, I decided to take a few moments to celebrate the coder-bloggers who do manage to transcend the usual "here’s the facts as I see them" style of tech-blogging and really make the English language dance, either by playing it like an instrument or by shooting at its feet.

So as to immediately contradict myself I’m going to start my celebration not with a blogger but with a particular post I read today and which, based on the title, I would never have bothered to read except that we’ve been flirting with XP here at work so it caught my attention. The post, The Agile 800 Pounds Gorilla [sic] is a mind blowing piece of satire. The author is clearly not a native English speaker and yet wields the language with more skill than 99.9% of the native English speaking technologists I have come across. (A Samurai armed with wiffle bat will still beat the snot out of a redneck armed with a sword.) The essay itself is a satirical tale of the mythical Enterprise, ceremoniously re-branding its Kafkaesque bureaucracy as an Agile process, and the melodramatic interpretive dance it puts itself through to prove its Agile-ness. The slightly faltering English completes the charm of the piece.

My favorite consistent voice in the blogosphere right now is that of Mike Duncan. If you like your entertainment and your education mixed together, read his blog. If I could write like Mike I’d quit my day job and blog for a living, something I wish he would do because his posts are pretty far and few between (but worth the wait).

A close tie with Mr. Duncan is Steve Yegge,  who is much more prolific. His writing is absolutely top notch and thoroughly entertaining even when the topic is mundane (which it rarely is).

My next favorite writing style is that of the mysteriously code named Ayende Rahien. His fragrant blend of an insatiable passion for programming, mildly haphazard English and penchant for metaphors is … unique. It is also thoroughly enjoyable. If you have a taste for language at all and want a very special treat read the Manning EAP edition of his book about building DSLs in Boo - it doesn’t matter if you have any interest in Boo or DSL’s (although you will get two treats if you do) - there is a wild carnival of language in store for you. Get the EAP edition though, for I fear they will edit much of the wonderful flavor out of it before it goes to production.

Speaking of which, I have seen Ayende’s signature "ellipses" construct , which I have termed the "pause for euphemism", being bandied about recently on Twitter. Fascinating. Never for an instant believe your mind is an island unto itself or merely the window of a cockpit from which you pilot your life - we are a seething sea sloshing into and through one another at every moment.

Finally, an honorable mention goes to Kyle Baley, The Coding Hillbilly. His blog doesn’t have the rigorous, consistent hilarity of Mike Duncan or Steve Yegge, or the spicy mad scientist-ness of Ayende Rahien, but it is light hearted, well written, and generously peppered with self-effacing hillbilly jokes. A pleasant and often amusing read.

I recommend subscribing to all of these folks immediately (although you probably are subscribed to them already). I read a lot of blogs, but most of the blogs I read out of a neurotic sense of fear that I will miss some critical piece of technical insight that would have enabled me to write software that provides real business value instead of software that inadvertently shorts out old people’s pace makers as they walk past our building. These few blogs I read for pleasure. And fear.

My interest in the REST approach to cross-process communication has been growing little by little over time like condensation on the back of my brain, almost without my noticing it. In the front of my mind I have always focused my energies on learning SOAP web services and The WS-* Way. Whenever there was a REST vs SOAP debate I always came down on the side of SOAP, citing the usual examples: electronically discoverable contracts, automatic proxy generation, security, encryption, transactions, WS-*, blah blah blah. I think, though, that despite my tendency to feel like I was making an informed decision based on available evidence, in reality I was simply borrowing my opinion from my environment rather than applying the strengths and weaknesses of the two approaches to the actual messaging requirements of the systems I was building.

When you are young and first start having adult conversations, and such a conversation turns political, many people will argue on behalf of an ideology inherited from their parents or older peers. Most can even argue intelligently and coherently using borrowed rhetoric. Some people may never grow out of this tendency, but many others will begin to combine their first impressions with their own unfolding experience of the world and either gradually or all of the sudden realize they no longer believe what they thought they believed.

In any case, despite my conscious disregard for REST whenever I bothered to think critically about it, the sheer volume of media coverage about the subject worked its way into my curiosity. After all, REST API’s are everywhere. Even WCF now natively and comfortably supports building REST based messaging endpoints. Then the other day I read this article and realized that while I’m absolutely sure everything I’ve learned to believe about SOAP is entirely true, the requirements of the systems I work on very often don’t actually demand (or justify) most of the strengths of SOAP (or the Gordion’s Knot of complex WS-* standards).

This realization didn’t suddenly swing my opinion to the REST side, the decision of which approach to use in any given situation will need to be made on a case by case basis, of course, but my toolbox grew three sizes that day. What surprised me about this experience is that I always felt I was weighing my options evenly and making technical decisions based on the parameters of the problem at hand, but in reality my mind was always already made up! There was never a real choice.

Maybe one of the more interesting kinds of professional growth is not just acquiring new technology skills, but also the shedding of these very subtle preconceptions that artificially limit your options.

Of course, not only are such unsubstantiated prejudices unavoidable but are also a complexity reducing necessity. If the entire gamut of available technology needed to be evaluated for every technical decision, you’d never make any progress on anything. Choices made by the subconscious, even when due to prejudice, keep the ball rolling.

There is no moral to any of this, though. I don’t think we have much control over the situation. Preconceived notions will continue grow and shed cyclically as long as we are alive, like a snakes many skins, and the conscious mind can do little more than take credit for the good decisions and apply shame for the not-so-good ones, but that’s how we roll, brotha.

Have you ever had the experience while learning a new set of technologies in preparation for building a new system that, as your research begins to accumulate and the architecture you are searching for begins to take shape in your head, there remain a few places where your nascent mental framework is “hung up” on some piece of dogma you perceive in the subject matter? You feel intuitively there must be a better way but can’t get past some oft-repeated edict or tenet even though it is getting in the way of a truly elegant design.

This is usually only applicable when you’re new to some way of thinking because hands on experience allows you to brush away these hang-ups like spiders webs; when you have some experience in something you understand the reasons behind the dogma and can ignore it intelligently when appropriate. When you’ve just arrived on the scene you take much of what you are learning as gospel, and how could you do otherwise? Your feet aren’t damp yet, how dare you challenge existing wisdom?

If you’re very lucky then just at the right moment someone will come by and un-hook the string tethering your thought process and everything will fall into place. That, at any rate, is what just happened to me last night. If you aren’t so lucky, it may be enough to at least be aware that if you are studying something new and it just seems awkward or unnatural to you in the environment you have in mind then there is a good chance either the technology you are considering is a poor fit for your scenario or, more likely, you’re taking some piece of guidance too seriously or are misinterpreting some best practice, so ask for help!

For myself, I was relieved of just such a hang up in the wonderful world of messaging. I was under the misconception that because we had chosen an asynchronous, queue based messaging paradigm (nServiceBus) for our inter-service communication that we needed to keep all messaging activity in the system within that paradigm, even when the fit seemed just terrible. Udi Dahan was kind enough to post about that exact topic in his blog last night, setting a critical thought-balloon free and allowing a system design unnaturally warped by an arbitrary constraint to find its natural shape in my mind. Now we can use a nice, clean REST API to power the MVC front end of our application without me feeling filthy and guilty and dreading the moment when we’d have to pay the devil for the transgression. (Thanks Udi!)

Yet another case case of someone walking into my brain, moving a single dendrite from neuron A to neuron B, and suddenly the world is a simpler place. My advice: do not ignore or take for granted these million odd micro-revelations in your career or your life, and each subsequent revelation will come more easily and more frequently.