Morning Coffee 63

  • My friend Christoph Schittko (who used to blog here, but hasn’t written anything in almost two years) recently wrote on an internal email thread that he “wonder[s] how many more attempts for “enterprise wide” thingies we need for people to figure out that there’s too much complexity involved to coordinate anything enterprise wide.” I couldn’t agree more, though I think it’s more than just complexity at work here. There are significant forces driving decentralization in society in general and IT in particular, and anything enterprise wide is by definition centralized.
  • I’m way behind on this, but Ray Ozzie did an fascinating interview with Knowledge@Wharton. I was especially interested in his separation of “big-I” and “small-i” innovation. Sounds like disruptive and sustaining innovation from The Innovator’s Dilemma to me.
  • According to Mary Jo Foley, my ex-teammate Mike Walker is “da man” on Office Business Applications, or OBA’s.
  • I think I have an old PocketPC hanging around in a drawer somewhere. Apparently, I can use it as a caller ID server instead of gathering dust. That’s sorta freaky. (via Backstage @ MED)
  • Quote of the Day: “If you have a live show on a TV network, Its not good to have a brain fart during a slow news week.” – Mark Cuban. Personally, I don’t care one way or the other about Don Imus, but Mark’s points about the conservatism of media corporations are spot on.

Morning Coffee 62

It’s a slow Thursday.

  • BPEL 2.0 has been approved as an OASIS standard. John Evdemon from my old team has the details. As I’ve written before, I think the spec is too heavily focused on executable process and not enough on abstract process. But I guess congrats are in order none the less.
  • Notepad2 v2 is out. Unfortunately, it still doesn’t support user defined syntax schemes. I wonder if the switch from GPL to BSD license might encourage someone to add that support? (via Larkware)

Is Guidance Automation Too Complex?

Over the past couple of weeks, I’ve gotten a chance to spend time investigating the Guidance Automation Toolkit. For those who aren’t familiar with GAT, it is the underlying enabling technology that powers p&p’s Software Factories. Several of p&p’s factories include data access guidance, but that works against an actual database rather than a VSTDB project. Given my newfound love for VSTDB + my interest in GAT, I thought I would whip up some simple automated guidance.

The key word in that last sentence is “thought”. Turns out that authoring guidance in GAT is extremely unfriendly. GAT’s unit of automation is called a recipe, which consists of arguments, wizards and actions. Arguments are GAT’s equivalent of variables, wizards gather argument data from the user and actions execute changes to the solution based on the values of the arguments. There’s more granularity to the GAT authoring model – for example, GAT arguments have optionally have value providers and converters (which should be called validators) – but you get the basic idea.

What makes GAT so hard is that all these recipe elements are wholly independent. This makes individual recipe elements easy to write and recipes fairly modular, but at the cost of making recipe very difficult to write. Your recipe has to define both the list of these elements that it uses as well as their interconnections. For example, arguments optionally contain value providers and converters. They are exposed to the user in wizards as either custom pages or arguments. They are fed into actions as input parameters. Action input parameters can also come from the output parameters of other actions. All these interconnections have to be hand coded in XML with fully specified type names like “Microsoft.Practices.RecipeFramework.VisualStudio.Library.Templates.TextTemplateAction, Microsoft.Practices.RecipeFramework.VisualStudio.Library”. Ugh.

The good news for GAT is that help is on the way. Clarius’ Software Factories Toolkit includes a graphical domain specific language for authoring recipes. With that tool, you can pick the various recipe elements from a list and connect them graphically instead of hand coding all of that in XML. But why do we have this problem in the first place? How much are we gaining by using this XML format in the first place? Frankly, I don’t think very much. I think it would make more sense to define recipes in code than XML.

I was talking to Michael Lehman about Project Glidepath, which is built on GAT. However, Glidepath only uses GAT for integration with Visual Studio’s menu system (which seems much more difficult than it needs to be, but that’s a separate post). Instead of GAT’s recipe system, Glidepath plugins simply expose an Execute() method. Within that method, the plugin can do whatever it wants. Michael showed me the code behind the Vista Bridge package, and it is MUCH simpler than the GAT equivalent. I could see having a little more structure than just Execute(), but GAT seems like overkill in comparison.

Sometimes complexity is necessary. But I can’t help but think that GAT’s complexity wasn’t really necessary. Wouldn’t it have been simpler and just as modular to define a recipe in code instead?

Morning Coffee 61

  • Nick Malik wonders if architecture is code or if it’s data? Frankly, I have nothing to add to this, but thought I should link to something Nick wrote since he’s letting me share his office for the next few months while I’m engaged with one of the teams he mentions, though he begged me not to disclose which one. 😄
  • Ted Neward’s Five Minute Management Lessons for Developers made me snicker.
  • Xbox.com is running a new contest called “My Mom’s a Gamer“. Mine is. These days, it’s mostly casual games on MSN Games, but back in the day she played both the Atari 2600 and Colecovision. She would play Space Invaders for hours. And curse. A lot. Most kids learned to curse on the playground, I learned from my mother.
  • Mark Cuban claims the HDTV is the new PC. TV and PC technologies are certainly evolving as they merge, but will that platform be as open as the desktop PC or the browser? It better be.
  • According to Nick Carr, Citigroup is looking to cut $4.6 billion in spending over the next three years and that IT will be one of the “cornerstones” (i.e. hardest hit) of that effort. I had a chat with an Meta analyst in Australia a few years ago who suggested that IT spending was going to go thru an innovator’s dilemma phase. Huge companies (like Citi) with huge IT budgets are facing significant competition from small companies that can’t afford huge IT budgets. These smaller companies get used to running a tighter ship and tend to be more competitive as they grow and are able to directly face off against the big fish.

Morning Coffee 60

My car has a new battery so I am back in the office with my nose on the grindstone. I’ve spent most of the morning talking about SOA and my MSIT project, so I only have a few items today.

  • Nicholas Carr illustrates the coming competiton between SalesForce.com and Google. Very interesting. Of course, that doesn’t damp “their mutual disdain for the Horrible Monster of Redmond” as Carr puts it.
  • I decre that Peter Schneider officially has too much time on his hands. I mean, if he’s got time to implement a compiler and interpreter for Brainfuck in Powershell, what else has he got time for? On the other hand, it’s short and shows how internal DSL friendly PS can be. (via Larkware)
  • Jeff Atwood wonders if MTurk is a failure. I wrote a year ago that MTurk is a successful feature, but would be a failure as a stand-alone service. As I wrote then, “I’m guessing it would be worth it to Amazon to run the service even if they were the only ones using it.”