Stuart Kent - Building developer tools at Microsoft - @sjhkent

  • stuart kent's blog

    Back to blogging - I've been tagged


    So I've not been blogging for a while. Sorry about that.

    What's my excuse? Well, I've been writing a book with my colleagues Steve Cook, Gareth Jones and Alan Wills.

    And, yes, they've kept up their blog, so it's not a very good excuse really (though book and five children doesn't leave much time for anything else).

    I've also been tagged now by both Steve and Gareth. Gareth tagged me a while back, which obviously failed to wake me from my slumber, and Steve has just tagged me. Now, as Steve says about himself "I never do chain letters", but I quite like the idea of telling you a few things about me you might not know. I won't tag anyone else, mostly because I see that those people I would have felt comfortable tagging have already been tagged.

    1. I'm married with five children and live in a converted barn on the top of the North Downs near Canterbury in the UK.
    2. I sing (more like used to sing) counter tenor in church choirs. Well, I guess it was a little more than church choirs. I was a choral scholar at Exeter cathedral whilst at University there, and then a Gentleman of Her Majesty's Chapels Royal in St James's Palace, London, whilst I studied for my PhD at Imperial College. There are two chapels in St James's palace: the Chapel Royal and the Queen's Chapel. I was married in the Chapel Royal. Whilst there, I also attended one of the Queen's garden parties at Buckingham Palace, and got to sing at a number of Royal events. 
    3. My first computer was a Sinclair ZX80 that my Dad built. My next was a Sincalir ZX81 that I bought myself (I remember spending a week in the sanatorium at school reading the manual just after I got the computer - I wasn't allowed to take the computer in). I learnt Z80 assembly code programming on the ZX81 in an attempt to build a arcade game. My third computer was a Grundy New Brain - a very rare thing indeed as the company wnet bust soon after I bought it. I still have the ZX81 and New Brain boxed away somewhere.
    4. My first programming job was in a robotics firm based in the village in Hampshire where I was brought up. I wrote Z80 assembly code for the controller of a steel rod cutting machine. Now that was fun.
    5. I went to a public boarding school (a 'private school' is called a 'public school' in the UK, and a 'public school' is called a 'state school' - don't ask me why) from the age of 8 to 16, when I left to go to university. There I learnt to play lots of sports - football, rugby, squash, cricket - though was not particularly good at any of them, although I did enjoy trying. I did get into the school cross country running team, though, and still enjoy pounding through the mud when I can find the time. And I was part of the choir that won the first ever National School Choir Competition.
  • stuart kent's blog

    Refresh of DSL Tools shipped in VS2005 SDK V4


    Gareth has the low-down:

    This is a bug-fix release for DSL Tools, and the final SDK release for VS2005.

  • stuart kent's blog

    DSL Tools V1 has shipped!


    Yes it's true - we've shipped!

    The DSL Tools web pages will be updated shortly, with more details about this V1 release. For those who can't wait, the VS2005 SDK V3 containing DSL Tools V1, can be downloaded from

  • stuart kent's blog

    DSL Tools documentation now available on MSDN...

    • 0 Comments the link

    This is actually the documentation for our version 1 release which will be available soon as part of the Visual Studio 2005 SDK version 3 release - see

    Note that the documentation isn't finished - we have a dedicated team still working on it - so expect further documentation releases until the end of the year.

  • stuart kent's blog

    DSL Tools V1 release - latest news


    Having just returned from vacation, I thought I'd update folks about the V1 release of DSL Tools. This will be shipped as part of the Visual Studio 2005 SDK Version 3 in the first part of September.

    We have signed, sealed and delivered our code to the VS SDK team who are now just wrapping up. There will be a significant new documentation drop at the same time, although we will continue to update the documentation until the end of the year.

    Apart from bug fixes, the main feature in this release is a completed Dsl Designer for editing .dsl definitions.

    I'll post again as soon as the toolkit has been released.

  • stuart kent's blog

    Storyboarding tool integrated with team system


    A while back I posted about how useful I find storyboards in the specification process.

    Now there's a tool integrated with VSTS for doing storyboarding. Check it out at

  • stuart kent's blog

    Jos Warmer on small models


    Here is a great post from Jos Warmer over on the DSL Tools forum.

    He makes some good arguments. Please add your own opinions to the discussion. We'll definitely take note as we think about the next set of features...

  • stuart kent's blog

    New dsl definition format


    Those of you who have downloaded the June CTP of DSL Tools will, by now, be aware of quite a few changes. In particular you'll have noticed that we've replaced the old .dd and .dmd formats with a single .dsl format, and provided a (currently unfinished) designer for this format.

    Whilst we're waiting for the documentation to catch up, I thought I would spend a few cycles telling you about the new .dsl format, and provide some insights into some of the thinking behind it.

    So where to start. Well, it's probably a good idea for you to take a look at a .dsl file. Follow one of the walkthroughs in the documentation that comes with the kit to get hold of an example.

    If you open the file in the xml editor, you'll see that it contains definitions for: classes, relationships, types, shapes, connectors, a designer, a diagram, plus sections to define xml serialization and explorer behavior, and a section to define things called connection builders.

    Looking a bit deeper, you'll see that a diagram defines shape maps (various kinds) and connector maps, that is, how shapes and connectors map to classes and relationships for that particular style of diagram.

    You'll also see that, as well as referencing the diagram to be used, a designer also defines one or more toolbox tabs, with tools on them.

    I'm going to focus in this post, and probably a couple after, on one of the key changes we've made, which is to make a clear distinction between how information in the model gets presented on the diagram, and the actions used to create new parts of the model.

    In the old dd format, you defined a shape, a class, and a map from class to shape, then a tool that referred to a shape. In the designer that was generated, using the tool caused an instance of the mapped class to be created together with an instance of the shape to view it. This scheme had the advantage of being simple, but the disadvantage of being very inflexible. Without a lot of custom code, you couldn't define (element) tools that did anything other than create an instance of a class embedded in the object mapped to the diagram with a new shape on the diagram viewing it. A restriction of this scheme was that it forced most classes in a domain model to be directly embedded in the root class.

    In the new format, the shape and connector mappings only govern how a diagram views the model: what shapes get created to view what model elements, and what connectors get created to view links of what relationships. The tools, in conjunction with merge directives and connection builders, govern how model elements and links get created in a model. An element tool refers to a class. It causes an element of that class to be created and merged into the model via the element mapped to the diagram or shape that the tool is dragged onto. Merge directives on the class of that latter element define the mechanics of the merge. A connection tool refers to a connection builder, which defines how the element mapped to the shape at the source drop point of the tool gets connected in the model to the element mapped to the shape at the target drop point of the tool.

    So we now have a definition in the style of the well-known model-view-controller pattern. Tools are the controllers, and are used to add stuff to the model, whose elements are viewed by shapes and connectors on the diagram, as determined by the shape and connector mappings defined for that diagram.

    Combined with the use of paths in the definitions of maps, connection builders and merge directives, plus the ability to flag the need for custom code at various key points, we end up with a very rich and flexible system for defining the interaction between the design surface and the model.

    In the next post, I'll walk through an example. But for now, I'll point you at a great post by Alan the reveals some of the details of paths, merge directives and connection builders. 

  • stuart kent's blog

    DLinq Designer


    Goto and download the latest CTP of LINQ. There you'll find a designer for DLINQ that's hosted in Visual Studio. Anything look familiar? Wondering what tools were used to build it? If you haven't guessed by now, here'e another hint: 

  • stuart kent's blog

    Sam has started blogging


    Sam Guckenheimer has started blogging -

    Sam is the chief product planner for Visual Studio Team System. He's also just written a book about it.

  • stuart kent's blog

    June CTP of DSL Tools now available


    I haven't written a blog entry for a while, and the reason is that I've been very busy working on the latest CTP of DSL Tools.

    I'm pleased to announce that it is now available.

    Details on the DSL Tools web page. When you get to the Visual Studio SDK download the page you'll need to scroll down to find the June 2006 CTP.

    We look forward to receiving your feedback.

    Existing users of DSL Tools, please take note of the Important information about migrating existing designers:

    "To migrate a designer produced with an earlier (though no earlier than November 2005) CTP for Domain-Specific Language Tools to work with this June CTP, you must have both the CTP with which the designer was produced and the June CTP installed on your computer. Therefore, if you have an older designer that you want to migrate, you should NOT uninstall the previous CTP before you install the June release of the Visual Studio SDK, which contains the June CTP of Domain-Specific Language Tools. You can migrate designers from older CTPs to the current one if you have the older CTP on one computer and the current CTP on another computer if you can copy files between the two computers."

  • stuart kent's blog

    VSTS Work Item Type designer


    Darren just IM'ed me to say that he had put out his first preview of the work item type designer he's been building with DSL Tools.


  • stuart kent's blog

    Japanese translation of Software Factories book


    Another belated announcement.

    The Japanase translation of the Software Factories book is now available:

  • stuart kent's blog

    Belated announcement of February CTP of DSL Tools


    I've been so immersed in getting V1 DSL Tools out the door, that I see I haven't posted a blog entry yet this year.

    I'm also very late in telling you about the new release of DSL Tools. The main purpose of this release was to integrate DSL Tools into the VS SDK, which it now is. There's also a significant refresh of the help documentation, which is also integrated.

    More details from Gareth at: 

  • stuart kent's blog

    Seven stages of models


    There aren't really seven, but it makes for a good title (look up "seven stages shakespeare" if you're feeling puzzled at this point.)

    Anyway, I've been watching a debate between Harry, Gareth and now Steven, on the process of building models, including how alike or unalike that is to programming. There also seem to be a number of different terms being suggested for the different states of models - terms like complete/incomplete or precise/imprecise. Now I start to worry when I see terms like that without concrete examples to back them up. So I thought I'd weigh in with some comments, and give a concrete example to illustrate what I mean.

    The general point I'd like to make is that I think models and programs do go through different states, like complete or incomplete, but I wouldn't try to use generic terms to describe these states. I think those states are language, dare I say domain, specific, and depend largely on the tools we have for checking and processing expressions in those languages, be they programs or models. So a program goes through states such as 'compiles without error' and 'executes' and 'passes all tests' and 'has zero reported bugs against it' and 'has passed customer acceptance testing'. At least the first three of those states are very specific to programming - we know what it means to compile a program, to execute it, to test it. We'll have to find different terms for different kinds of model.

    And if I was going to use a generic term for the sliding scale against which we can judge the state of a model or program, I would use the term 'fidelity', as it has connotations of trustworthiness, confidence and dependibility, which terms like 'precision' and 'completeness' don't really have.

    So now for an example of stages a model might go through, taken from my very recent experience as we are developing Dsl Tools (I apologize for the mild case of navel-gazing here).

    In the last few days I've been developing a new domain model for the new Dsl definition language that will replace the designer definition (.dsldd) file we currently use in Dsl Tools. There are various stages which that model goes through. I don't bother with sketching it on paper, as the graphical design surface is good enough for me to do that directly in the designer. I miss out lots of information initially, and the model is generally not well-formed most of the time. However, I then get to a point where I'm basically happy with the design (or as happy as I can be without actually testing it out) and I'm ready to get it to the next level of fidelity. Let's call this 'Initial Design Complete'.

    For the next step, I start by running a code generation template against the model, which generates an XSD. This usually fails initially, so I then spend time adding missing information to the model and correcting information that is already there. Finally the XSD generation works - I have more faith in my model than I had before. This is the 'XSD generation succesful' state.

    Now I've got the XSD, I develop example xml files which represent instances of the domain model I'm building (in this case, particular dsl definitions) and check they validate against the XSD. I find out, in this stage, whether the model I'm building captures the concepts required to define Dsl's. Can I construct a definition for a particular Dsl? As these examples are built, I refine the domain model, and regenerate the XSD, until I have a set of examples that I'm happy with. The fidelity of the model is increased and I'm much more confident that it's correct. We might call this the 'All candidate Dsl Definitions can be expressed' state.

    The next stage, which will now mostly be done by developers I work with, is to write the code generators of this new format that generate working designers. We'll write automated tests against those generated designers and exercise them to check that they have the behavior we expected to get from the Dsl definitions provided as input to the code generators. This process is bound to find issues with the original model, which will get updated accordingly. This might be the 'Semantics of language implemented' state, where here the semantics is encoded as a set of designer code generators.

    So how is this process similar to programming? Well, with programming I'd probably do my initial sketches of the design on a whiteboard or paper. I might use a tool like the new class designer in Visual Studio, which essentially visualizes code, and just ignore compile errors during this stage.

    When I think the design is about right I'll then do the work to get the code to compile. I guess that's a bit like doing the work in the modeling example above to generate the XSD.

    Once I've got the code to compile, I'll try and execute it. I'll build tests and check that the results are what I and the customer expect. This, perhaps, is analagous to me writing out specific examples of dsl definitions in Xml and checking them against the generated XSD.

    We could probably debate for ages how alike generating an XSD from a domain model is to compiling a program, or how alike checking that the domain model is right by building example instances in XML is to executing and testing a program. I don't think it really matters - the general point is that there are various stages of running artefacts through tools, which check and test and generally increase our confidence in the artefact we're developing - they increase the fidelity of the artefact. Exactly what those stages are depends on the domain - what the artefact is, what language is used to express it, and what tools are used to process it.

    Now it would be interesting to look at what some of these states should be for languages in different domains. For example, what are they for languages describing business models...

    [10th February 2006: Fixed some typos and grammatical errors.]

  • stuart kent's blog

    The ideal tool...


    Just noticed this little nugget over on Steven's blog at MetaCase (just gloss over the blatant marketing):

    "Obviously the ideal tool would be as fast and powerful to use as MetaEdit+, and have its maturity, but also have the extensibility of Microsoft's DSL Tools, without crashing into the customization cliff. It should however run on all platforms like MetaEdit+, but be tightly integrated to Visual Studio, Eclipse, and vi. And be free, with complimentary commercial support. But I digress..."

    And whilst we're using it, we can stare dreamily out of the window and not be surprised as we watch a pig float gently by in the warm summer breeze...

  • stuart kent's blog

    DSL tools samples download now available


    Like buses, you wait a while then two come at once. That's right, just a week after we released the latest version of DSL Tools, we've also released an update to the samples. This download includes:

    1. A complete end-to-end sample of a project in which most of the code is generated from a DSL, and the use of the new validation and deployment features is illustrated. A detailed guide describes the features and their use.
    2. Examples of using custom code to enhance languages developed with the DSL Tools, together with a detailed guide. Features demonstrated include: computed properties, constraints on connections, line routing, shadow & color gradient control, shape constraints, and template-generated code.

    (1) is brand new. (2) is an update of the samples we released a few weeks ago.

    And next? We should get some more documentation up soon, and we're working on integrating the release into the VS SDK. After that, you'll have to wait a while as we do some root and branch work on some of the APIs and replace the .dsldmd and .dsldd with a single .dsl format, with it's own editor (yes, editing .dsldd files will become a thing of the past). We'll also be supporting two more pieces of new notation - port shapes and swimlanes, and providing richer and more flexible support for persisting models in XML files. Our goal is a release candidate at the end of March. 

  • stuart kent's blog

    The creator of WiX blogs about the deployment feature in the new release of DSL Tools


    In the latest release of DSL Tools we make use of the WiX toolset to create MSIs. Rob Mensching, the creator of this toolset, has blogged about what we have done. Without WiX, our job would have been much harder in implementing this feature... so thanks, Rob.

    Rob also mentions Grayson Myers in his blog. Grayson is a dev on the DSL Tools team who implemented (and, to be frank, designed) this feature. Rob is right to compliment him on his efforts.

  • stuart kent's blog

    New release of DSL Tools available


    Our next release of DSL Tools is now available.

    This release works with the final released version of VS2005. Goto the DSL Tools website at to download it.

    This is the release I talked about in my blog entry at

  • stuart kent's blog

    Automating tedious tasks (2)


    In my last entry I talked about how to go about automating tedious tasks for developers. Of course, developers are not the only people involved in software development. What about automating stuff for everyone else?

    Part of my job involves project management, and recently I've experienced the joy of having tasks automated for me. In particular, as described in an earlier blog entry, I have been able to set up a spreadsheet to connect to the work item tracking system in Visual Studio Team System and have burn down charts created for me (nearly) automatically - takes me 5 mins per day to update them. (I have talked with the team system guys, and it looks like I can do even better, using some of their built in reporting facilities - I just don't know how yet.) This has freed up loads of time, which I can now put to good use in the creative aspect of program management - working out what the product needs to do now and in the future, working through scenarios, writing specs, working closely with developers. I get the added benefit of having real-time tracking data at my finger tips which helps me identify risks and problems earlier.

    One aspect of Team System that I like a lot, is its configurability. They realized that a closed world solution was not going to acceptable in managing software development projects. So they've made sure that you can get at the data through APIs, that you can design your own work item types (every organization needs to record slightly different information to the next), that the data can easily be exported to the Microsoft Office applications Excel and Project, that there's linkage to sharepoint for document storage. This makes it much more likely that you're able to customize the product to automate tasks that suit you or your organization's way of working. And so I've found for the work that I have to do.

  • stuart kent's blog

    Automating tedious tasks


    I've just added a new byline to my blog: automating tedious tasks.

    A complaint often levelled at Software Factories is that it will turn developers into automatons, just pushing buttons to drive the factory to do all the clever stuff. I think the exact opposite is the case. The point of technologies, such as DSLs, which we're building to support the Software Factory vision, is that they are focused on removing those tedious and boring tasks, thereby releasing the developer to focus on the creative and interesting parts.

    For example, you can write some code by hand which uses the same label in a number of places, as part of a property name, part of a class name, to identify a database, in the title of a web page, and so on, and then every time that term changes (which it will) you have to go and make the change by hand in all those places. Wouldn't it be better if we had tools which allowed you to identify that the particular label was used in a number of places, and then propagated the change to the label in all the places it's used whenever you need to change it? Then, instead of looking at an hour or more spent laboriously working through the code changing all uses of the label, you can do that in a couple of seconds and spend those hours trying to work out that tricky algorithm you've been stuck on. 

    DSL Tools supports something like this. We're lowering the bar to defining small domain specific languages from which code can be generated. So the label referred to above will be captured in one place, in an expression of the DSL, and change to that label will be propagated to all the places it's used by the code generators. Now, in DSL Tools at present, code generation is fairly crude (but still useful). You can generate complete text files - as many as you like. This does mean that if you need to write custom, hand-code to finish off the generated code, you need to put it in separate files. With the partial class facility of C#, this is not so restricting as it might seem (assuming you're coding in C#, that is). I fully expect developers writing and adapating the code generators, as much as I expect them to be writing the custom code in the carefully worked out plug points. Our challenge, as vendors of a tooling platform, is to enable this way of working at a finer level of granularity and with an even lower bar to entry.

  • stuart kent's blog

    Using VSTS with Excel for task tracking


    I've had reason recently to use the task tracking features in Visual Studio Team System. We've been tracking our bugs for some time in VSTS, and wanted to move over to tracking tasks there as well - it's so convenient to have it all in one place. The blocker was that we had been using spreadsheets to generate glide path or burn down charts of task effort against time, with the tasks lists being maintained in the spreadsheets. This is not ideal as you can't query the lists very easily, it's yet another environment for team members to work in, and the lists get split over a number of spreadsheets (e.g. by feature crew) to make them manageable.

    I had heard about the Excel integration that VSTS provides and thought I'd give it a go. An hour later, and I had an Excel workbook refreshing a task list in one worksheet by running a predefined query against work items in VSTS, and then, through the magic of Excel formulae (the SUMIF function was particularly useful) I was generating a glide path chart of actual against planned. I also had another spreadsheet giving me a breakdown of remaining work by person. Now as developers close tasks, or update them with completed work, the changes can be reflected in the chart and table at the press of a button. This gives us real-time data on the progress of the project, allowing us to be more agile.

    So, congratulations to the VSTS team. This is good stuff.

  • stuart kent's blog

    Writing a book


    I see that Steve has let the cat of the bag - we (that is Steve, Alan, Gareth and myself) are writing a book on DSL Tools.

    Let us know if there are particular topics you'd like to see covered.

    We'll try and blog about some of the content as we write it. 


  • stuart kent's blog

    DSL Tools with Visual Studio 2005 RTM


    Now that Visual Studio 2005 has been released to manufacture (RTM), folks are asking us when to expect a version of DSL Tools that works with the RTM release. Well, you won't have to wait long - it should be available within the next two or three weeks. And we've got two new features lined up for you as well:

    Deployment, where you create a setup project for your designer authoring solution using a new DSL Tools Setup project template, which, when built, will generate a setup.exe and a .msi for installing your designer on another machine on which VS2005 standard or above is installed.

    Validation, where it's now possible to add constraints to your DSL definition which can be validated against models built using your designer. Errors and warnings get posted in the VS errors window. We support various launch points for validation - Open, Save, Validate menu, and these are configurable. All the plumbing is generated for you - all you have to do is write validation methods in partial classes - one per domain class to which you want to attach constraints - which follow a fairly straightforward pattern.

    We're also going to release our first end to end sample about the same time. The sample is a designer for modelling the flow in Wizard UI's (it's state chart like), from which working code is generated.


  • stuart kent's blog

    VS Team System Virtual Labs


    You can now try out DSL Tools and other aspects of Visual Studio Team System, without going to the trouble of installing them, using one of the online virtual labs. See Rob Caron's recent posting for details.

Page 4 of 7 (152 items) «23456»