Stuart Kent - Building developer tools at Microsoft - @sjhkent

June, 2008

  • stuart kent's blog

    Long Time No Blog, UML and DSLs

    Technorati Tags: ,

    Embarrassing, but true. Last time I blogged was back in February.

    I'm on one of my regular trips to Redmond, and jet lag still means I'm getting up at 4am. Usually on these trips I use the early morning to do a bit of work, then go for a run. However, last trip I stumbled on a tree root when out running and fractured my ankle. It's the first time I've broken a bone, so I didn't know what to expect. In fact, at first I didn't really believe the doctor; x-ray looked fine to me. Little did I expect that I'd be back in Redmond 7 weeks later, still limping and definitely unable to run. So I find myself with more time in the morning, and an opportunity to contribute once again to the blogsphere, though any readership I may have had has probably already given up on me.

    So what's there to talk about. As the title suggests, I thought I would touch on the subject of UML and DSLs given a recent post on UML + DSL from Cameron Skinner, who now leads Visual Studio Team Architect. In the article, Cameron talks about a new set of designers that Team Architect are working on, which includes some UML designers, as well as some graphical DSLs. The goal is to 'make modeling more central to a broader range of people' as well as to 'seamlessly connect the two approaches [UML and DSL]'. We've found that DSL Tools is very appealing to customers who've already bought into modeling. It allows them to create their own customized model driven solutions fairly quickly. However, for those not already into modeling it's a harder sell (although, we have had customers who have seen what others have produced and decide to build something similar which focuses on their domain). To really get modeling out to a broader audience it's necessary to have tools that people can use straight out of the box. I'm still convinced that if you want to dramatically increase productivity then you should be using DSLs driving code generators, or further model transformations, or visualizing abstractions discovered from existing artifacts, or some combination of all three. On the other hand, whatever your views are about the effectiveness or not of UML, it has significantly raised the awareness of modeling with a broad audience and it is something that many people are familiar with. So I'm really pleased that Team Architect has now stepped up to drive a strategy that delivers on both sides of the modeling coin, and connects them up.

    What is more, I'm really enjoying helping them deliver on this strategy by providing a great platform to build on. Because, as Cameron points out, many of the designers being built by Team Architect (including the UML ones) are being built on the DSL Tools platform. Not only is this further proof for the robustness and flexibility of this platform, it is also helping to drive new features into the platform which will benefit anyone wanting to build their own DSLs. We're not ready to talk about those features in detail yet, but my list posted a few months ago is still fairly accurate, although there are a couple of additions and some changes in priority. Worth calling out are the features to allow a designer to be extended with new metadata once it has been deployed, and support for designers and models to interact. This will allow the designers delivered by Team Architect to be extended, and for new, third party DSLs to interact with them. Both these are key aspects of connecting UML with DSLs in the UML + DSL story that Cameron speaks about. 

    Finally, you may also have noticed that Steve is changing his role, by going back to Team Architect in order to help them deliver on the UML + DSL vision. This means that Steve will be more of a consumer of the platform that he helped create, and I'm sure will be driving hard to ensure that it meets his needs. Steve and I still share an office in the UK and will still be working closely together. Should be a fun ride, this.

  • stuart kent's blog

    Catching Up


    So now I've found myself some time to get the blog started again with Long time no blog, UML and DSLs here's a little catch up on all things VSX and DSL.


    Jean-Marc Prieur has recently joined the team as a program manager. Jean-Marc is a colleague of mine in Cambridge, and it's great to have him join us. Jean-Marc will be helping with both product work and driving community activities in Europe.


    As usual, Gareth has been summarizing others'

    blogs with lots of interesting links. Take a look at Couple more VSX bloggers and A rash of bloggers. has recently published a paper about adding prototype (pattern) support to your DSL. There's a video to go with it.


    In case you missed it, VS 2008 SP1 Beta has been released, together with a matching SDK. See Visual Studio 2008 SDK 1.1 Beta has shipped from Quan for details. Service pack releases focus on fixing bugs and increasing overall quality. For the Dsl platform, we fixed some bugs around line routing when using nested shapes. For those of you who have our book, this means that you can follow the instructions on pages 443 to 446 to implement nested shapes, rather than adopt the workaround on pages 446 to 453. The bugs we fixed remove the problem described at the top of page 446. We also provided a print preview feature. Run your designer on SP1 and you should see this capability just appear.

    Technorati Tags: ,
  • stuart kent's blog

    Agile platform development. The problem.


    Classic scrum

    Our team uses Scrum to manage it's software development. A key tenet of Scrum is that there should be a product manager (PM) who own's a backlog (that is, a ranked list) of customer facing stories. Scrum organizes development work into sprints, typically 3-4 weeks long. Before each sprint, there is a sprint planning exercise, where:

    • the PM communicates the stories to the engineering team
    • the team tell him or her what's possible and where the engineering dependencies are
    • the team estimate how long it's going to take to build each story, and, by identifying 2-3 day tasks required to develop that story
    • the engineering capacity for the sprint is worked out, taking account of vacation and other activities
    • they all agree what the main theme of the sprint is - what's the overall goal of their work this time round
    • with all that information the PM and engineering team narrow down the scope of stories, re-rank, and draw a cut line

    Need - build a (tooling) platform in an agile way

    Now I'm part of a team in the business of creating a tooling platform, including tools built on the platform to build other tools that work on that platform (tools to build tools). And my job as a program manager is to come up with those stories that can be used to drive sprint planning. And I also want to do it in an agile way, so that it can be managed by the same process, and in a way that fully exploits the creativity, ideas and expertise of all members of the engineering team for whom I have the deepest respect.

    Problem 1: Mind the gap

    A problem we've identified with classic scrum is that it doesn't take into account the often large gap between business need and the software solution proposed to fulfil that need. Indeed, the process assumes that somehow the product manager will pluck out of thin air customer facing stories which are fine-grained enough to make sense to feed into the sprint planning process. That may work if the project is about adding new functionality to an existing website, say, but with a platform it's not so obvious how this should work.

    Problem 2: Two or more customers

    When building a platform, you've got two customers at least. You have the customers who use applications built on the platform, and you have the developers who use the platform to build (author) those applications. I tend to call these users and authors. With a tools platform, there's also a third customer, which is the one who uses the applications built using the tools built on the tooling platform. This impacts the way you write scenarios/stories, specifically there are stories targeted at the user and stories targeted at the author. It also impacts the meaning of 'agile'. Platform has to be delivered in time for the authors to build the applications on that platform that their customer needs. If the author is running an agile process to build their application, then you're going to need to understand their stories some sprints before the author is going to implement them, so that you can get the platform pieces in place for them to build on in time. Or you try to do it all at once, but there lies a hornets' nest.


    After 5 years experience of doing this in Microsoft, I'm starting to get a handle on a process that seems to make sense, and I thought it would be fun to try and relate that process here and see what others think.

    So watch out for postings with a title of the form:

    "Agile platform development. ..."

    I'll also tag them as follows...

Page 1 of 1 (3 items)