I’m slowly but surely working through my holiday backlog of email and weblogs. Slowly being the operative word here.

Anyway, Stuart has a great post on the process by which we build models. And he’s not talking theoretically here, he’s working on a model for the designer definition file in the DSL toolkit. (Which is good news in and of itself as hand-writing the XML dsldd file is a pain in the butt. Though until then there’s the great Dm2Dd tool from Modelisoft). The iterative process he describes certainly looks a lot like development, in the same way that C# development looks like C development. Similar steps taken on different concepts. Additionally, he’s working bottom up – the output of the model will eventually be a working program (a designer in this case) which is the point I made in Abstraction Gap Leapfrog. There are existing abstractions that work now (i.e. the code generated from the existing dsldd file) and he’s trying to building something one level up from there.

I also like Stuart’s use of “fidelity” instead of my use of “complete”. Stuart uses it as an indication of how correct a given model is. That’s what I was implying when I said “complete” but “fidelity” captures the idea much better. I could imagine both lo-fidelity and hi-fidelity models for a given domain, though I would imagine you would always want to use the highest fidelity model available. The difference would be the amount of custom code you have to write – the higher the model fidelity, the less code you write by hand. And I would imagine the model’s fidelity would evolve over time, which introduces interesting questions regarding language evolution as well as the evolution of projects built with those languages.

I hope Stuart keeps blogging about this project.

While my blog was down, Microsoft launched the Xbox 360 with significant fanfare and dramatic demand. Of course, a month later the Xbox 360 is still sold out pretty much every where you go. I remember I got able to find an original Xbox before Christmas back in 2001 so either the demand is much higher or the supply is much lower (probably both). I’ve personally decided to wait on getting a 360 – I’m way behind on original Xbox games and my two kids don’t leave much playtime anyway. But I’m certainly in the minority on this one.

Anyway, at the height of the frenzy a couple days after launch, John Porcaro wrote what I thought was an amazing post about the difficulties of marketing a product like Xbox 360. I mean, we’re all acutely aware of the technical challenges of designing a hardware product like Xbox 360 or a software service like Xbox Live. Maybe that time in marketing rotted my brain, but the challenge John describes is significant.

Furthermore, I think John really lays it out there in his post. It may not have been good news (i.e. Xbox 360 shortages for the near-term future) but it was open and forthright about where Microsoft is with the Xbox 360 and how Microsoft wants Xbox to grow.

(Note: AFAIK, I am not getting a free Xbox 360 from John for writing this.)

One of the cool things about having a blogging conversation with someone on the other side of the world is that while you sleep they are thinking of a good response to your post. The only downside? Having to deal with rampant misspelling like “artefacts”. 😄

Anyway, Gareth responds to my post:

Until we get models that are perfectly aligned with our business domains, we’ll have people who want to create models but who get them slightly wrong from a precision point of view – usually in the places where the imperfect models interact with other aspects of the system across or down the abstraction stack.

With code, you’d likely not want to have people check in sources that don’t even compile and then hand them off to other folks who do make them compile, but I think that’s exactly the type of process we’ll see emerging in modelling for a while. I feel this way because I don’t foresee us getting modelling languages of pure business intent 100% right for some time yet – we’re simply not close enough to formal enough descriptions of systems as intensely human as a business yet. However, I hope we won’t want to try and keep modelling as locked away with the techies as traditional development has been. (Hope I’m not talking myself out of a job here…)
[Pseudomodels and intent]

I keep saying incomplete and Gareth keeps saying imprecise, but I think we can both agree on the term “imperfect”. There’s a massive difference between having an precise language that is imperfect versus a language that is inherently imprecise like UML.

However, I think the primary disconnect here has to do with Gareth and my views on how higher abstracted languages will evolve. Gareth’s comments about modeling “pure business intent”, having “models that are perfectly aligned with our business domains” and not “keep[ing] modelling as locked away with the techies” imply to me that Gareth wants to work down from the high level business abstractions into implementable technical abstractions. Frankly, I don’t think that’s very likely. Leapfrogging a few levels of abstraction hasn’t worked well in the past (CASE and UML/MDA) and I don’t think it will work well now.

I find it much more likely that we will build higher level abstractions directly on top of existing abstractions. Again, this is similar to the way C++ built on C which in turn built on ASM. Sure, that could keep modeling “locked away with the techies” for a while, but we’re already beginning to see the light at the end of that tunnel. Windows Workflow Foundation is a significant leap in abstraction while also being something than non-techies can use. Reports about about Sharepoint “12″ embedding the WF engine and FrontPage “12″ providing a Workflow Designer for building SharePoint workflows. While I imagine (and I haven’t used any of the new Office “12″ suite so this is pure conjecture) these WF tools are targeting the “power user”, they certainly aren’t only for developers.

Believe me, I would love to be wrong about this. I would much rather work down from or business user intent than up from the technical foundation. I just don’t think it’s feasible. The process Gareth describes breaks the “Model Transformation must be Deterministic” tenet of Code is Model, though the word “must” may be to strong to allow for language evolution.

Gareth responds to the first tenet of Code is Model:

[A]lthough as an industry we desperately need to drag models kicking and screaming from the far left of pretty-picturedom a good long way to the right in the direction of precision, I don’t want to throw the baby out with the bathwater.

I’m going to take it as a given that folks believe that precise models are valuable development artefacts. Why do I think imprecise models are also valuable? Here are three things that tools for imprecise models help you to do:

1. Communicate with people about design
2. Think out loud in a way that’s more shareable that your whiteboard
3. Start with an imprecise model and progress gradually toward precise models

Hopefully the first of these is obvious – there is value in model as communication device – it’s just not enormous.  I’ve talked before about the value of the second – I draw pictures on my whiteboard and when I’m on a conference call to Redmond, they’re effectively useless.

The third is something I’ve only recently become a convert to.  I’m happy to have models which are not precise so long as I can still reason about them programmatically.  This allows me to have development processes that are about a quantitive process of iterative refinement.

Here’s an example – in some infrastructure modelling tool, I have a node type which specifies a logical machine group.  One of its properties is the number of actual machines required to suit the proposed scale of the application to be deployed.  I’d like to be able to put “Depends on outcome of Fred’s scalability investigation” into that numeric field, or perhaps “4->8″.  I can still generate a pretty good report from this model, but I can’t really provision a set of physical servers from it.

But here’s the kicker – it’s vital that I can write tools that programmatically assess this model and tell me what work needs to be done in order to make it precise.  I want to know exactly what must be done on this model before, for example, it is suitable for feeding into some kind of provisioning tool.  You might say it needs to be precisely imprecise; I prefer to think of it as quantifiable imprecision.

[Imprecise Models and Killing Hippies]

The only thing I disagree with Gareth about is terminology. Like the term architecture, model has become a catch-all for things that aren’t code. Regular readers of this blog know I like to be more precise than that. As such, I think items #1 and #2 from Gareth’s list aren’t actually models at all. I think of them as pseudomodels, similar to the concept of pseudocode. Actually, I like the name pseudomodel – it also applies well to Grady’s scaffolding. Like psuedocode, pseudomodels have tons of value in communication and reasoning about a problem but they can’t be used as development artifacts.

As for the third, I think what Gareth is describing is an incomplete model, rather than an imprecise one. If the model is imprecise, there’s no way to programmatically reason about it. But if we look to code as an example, obviously, there are many cases where code is incomplete. Every compiler error you’ve ever seen is an example of incomplete code. And because the language is precisely specified, the compiler can tell you what needs to be done in order to make it precise, exactly as Gareth requested. I don’t think of writing code as “progressing gradually towards precision” and I doubt anyone else does either. And while I do see development as an “iterative process”, I don’t think of it as “iterative refinement”. Modeling shouldn’t be any different.

One area where I do see refinement being critical is in the development of the modeling language itself. Traditionally, the language stays stable while the program written with it changes. But with the introduction of DSLs, it becomes possible for both to vary independently. I would assume that a DSL would evolve over time to have better “coverage” of a given domain. For example, if I was building a CAB DSL, I would implement support for WorkItem right off the bat, but supporting WorkItemExtension would be much lower on the priority list. This represents language refinement, but I would argue it’s a refinement of coverage not a refinement of precision.

I’m digging the new Custom Domains service from Windows Live. Setup couldn’t have been smoother:

• Sign up on Custom Domains
• Change the MX record of my domain
• Add Users

The only even slightly tricky point is that I had set up a passport for harry@devhawk.net in the distant past and long forgotten the password. However, Custom Domains allows be to “evict” a user from the domain so I was able to recreate it with little trouble.

I do have two feature requests that I’m guessing are on the horizon for the Custom Domains team:

• Aliases: I’d like to set up “webmaster@devhawk.net” to simply forward to my main devhawk email. This is a pretty common feature of other email systems, so I expect some future release will include this.
• Non-Web Client Access: I can use Outlook to access my personal hotmail account, but I had issues accessing my devhawk email.