Morning Coffee 114 - MoMAAB Edition

• We spent all day yesterday discussing four topics: SaaS, Tools for Scrum, Web 2.0 and Domain Specific Languages. Even though it was just a day, my brain is full. These were deep and challenging discussion. I need to let the discussions stew a bit before posting anything about them here. But I will.
• Next time we do one of these, I'm bringing a video camera. I took notes, but looking over them the next morning they seem woefully incomplete. OneNote's integrated audio/video recording capabilities would nicely augment my notes.
• We ran this meeting using Open Space, and it worked very well. Of course, we only had 8 people, so we didn't need a lot of process to self organize. However, it did whet my appetite for having a larger Open Space style un-conference for architects. Is that something other folks might be interested in?
• Major thanks to the folks at Clarity Consulting who graciously gave us space to meet and fed us yesterday. Their CTO Jon Rauschenberger sat in on most of our meeting, and drove our Web 2.0 discussion. I said I wanted to stew a bit on the discussions, but Jon's slides are available on line if you're interested.
• Scott Colestock showed me Diigo, a social annotation tool. Where del.icio.us lets you tag and annotate individual pages, Diigo lets you annotate and highlight specific parts of the page. They also have blogging tools, where these annotations and highlights become blog posts, but they don't support dasBlog. However, since FeedBurner doesn't support Diigo for link splicing, I'm afraid my use of it will be limited.
• Jim Wilt introduced me to Virtual PC's command line. He recommends using "-pc <vpc name> -launch -singlepc" which launches a single virtual environment without the VPC console. I rarely run more than one VPC at a time and I hate stuff cluttering up my taskbar and notification area, so I like this a lot.
• Loren Goodman demonstrated the SharePoint Explorer Client. SharePoint & MOSS came up several times in all of our topics, so this is going to get a second look. I always thought it was strange that MSFT ships a smart client for editing WSS & MOSS, but not viewing it. SP Explorer looks like it fills that gap nicely.
• Shannon Braun sent us all a link to the 50/70 rule, which seems like a good rule of thumb. Of course, assuming that things won't progress linearly is almost always a good rule of thumb. But the 50/70 rule has reasoning behind the assumption.
• Chicago is nice, but the weather has been a little freaky. It's either been hot & humid, downporing thunderstorms or tornados. Keith Powell showed me FlightAware, which shows you flight departure and arrival history. My flight hasn't left within an hour of scheduled departure in a week. I'm going to try and grab an earlier flight, but I have a feeling it's going to be a long trip home.

Fantasy, Free Code and the SharePoint Model

It might sounds like a fantasy, but Nick Malik really wants free code. He started talking about it a few months ago when he was getting raked over the coals by debating Mort with the agile .NET community:

Rather than look at "making code maintainable," what if we look at making code free.  Why do we need to maintain code?  Because code is expensive to write.  Therefore, it is currently cheaper to fix it than rewrite it.  On the other hand, what if code were cheap, or free?  What if it were cheaper to write it than maintain it?  Then we would never maintain it.  We'd write it from scratch every time. 

Then about a week ago, he laid out the reasons why free code would be a good thing. At a high level (Nick's blog has the details), those reasons are:

1. Lower the cost of IT through reduced skill requirements. 
2. The speed of development goes up. 
3. Projects become more agile. 
4. Solution quality goes up. 

Talking about the benefits of free code is sorta like talking about talking about the benefits of dating a movie star. The benefits are actually pretty obvious, but talking about them doesn't really help you get there from here.

Actually, Nick isn't suggesting that all code can be free. He's focused on separating out business process modeling/development from the rest of software development. In essence, he's describing a new class of developer (should we call the persona Nick as an homage?) who needs their own class of tools and for the IT department to "formally" allow them to "easily develop, test, and deploy [aka host] their processes." For the most part, these BP developers wouldn't be traditional developers. They'd be more like software analysts who do the work directly instead of writing specs for developers.

I call this separation of business and IT concerns the SharePoint Model. SharePoint, IMO, does an amazing job of separating the concerns and needs of business and IT users when it comes to running intranet web sites. Only the truly geeky stuff that requires specialized access, knowledge or equipment - installing the SharePoint farm in the first place, keeping it backed up, installing service packs, etc. - is done by IT. Everything else is done by the business folks. Need a new site? Provision it yourself. Need to give your v-team members access to it? Do it yourself. I see similarities in the free BP code approach Nick's suggesting. I'd even argue that SharePoint is the natural "host" for such business processes. It already supports WF and can provide access to back-end enterprise data via the Business Data Catalog.

On the other hand, some of what Nick suggests seems fairly impractical. For example, he thinks IT should "formally and officially take control of managing the common enterprise information model and the business event ontology." First off, who officially manages this today? Does such an official information model or event ontology even exist? I'm guessing not. That means you've got to start by getting the business people to agree on one. That's usually a sucker's bet. Nick also suggests we "reduce the leaky abstractions" in our services. To suggest this is even possible seems incredibly naive.

The good news is the things that will work (evolving BP into its own development discipline, building custom tools for BP development, getting IT into the BP hosting business) don't depend in any way on the things that wont work (getting lots of folks to agree on anything, breaking the laws of physics, overcoming the law of leaky abstractions). I'm not sure it will result it truly free code, but it sure would bring the costs down dramatically. Thus, I think most of Nick's free code vision is quite practical and not a fantasy at all.

As for dating a movie star, you're on your own.