Agile at Microsoft: Developing XML Notepad

Following up on our coverage of XML Notepad's rebirth in Sept, InfoQ had the opportunity to interview Chris Lovett of Microsoft's XML team regarding XML Notepad and its development process.  XMLNotepad is a free XML editor written in C# with features like a search tool that supports RegEx and XPath, an XSLT transformation results view, and a schema validator.  The interview is about software development processes used to build the product (see also Microsoft countingon Scrum and XP), not about Notepad itself. 

InfoQ: What development process did you use to create XML Notepad?

We're using an " Agile Development Process" for these kinds of tools, which means it's a highly iterative process. We prototype the idea, show it around, get feedback, lots of hallway discussions, great feedback gets incorporated into the next iteration and so on, until we reach the point that we think we have the right set of features to call it done. So it's a light weight process with a small team that can move fast and respond quickly to feedback. Specifically we do one month iterations with a "feature team" consisting of developers, program managers and testers (3-10 people in all). Jointly the feature team has a high sense of ownership over the product. At the end of each month we do a "showcase" meeting where results of the work are presented to management, and then planning happens for the next month. Bigger changes in resourcing or direction for the product can happen at this point. This checkpoint stops a project from going off into the weeds too badly. This monthly cycle seems to work really well. The interesting thing is we're trying to move all product development to this sort of agile model. There's no reason why a single feature of a large product can't be thought of as one of these smaller application efforts. You just do a lot of them in parallel.

InfoQ: Compared to how you used to work, does this process seem to work significantly better or is it just different?

To be honest, it is what we've always been doing on this kind of project, we just have an official name for it now. It is the process that makes sense. Generally at Microsoft the process is there to serve the team, the team is empowered to make the process work for them not the other way around. Massively parallel development on large projects is just plain hard, so we generally have to put a lot more process in place to help manage that. But even there each feature team is free to add more process that is specific to their project. For example, if one team is doing a performance critical piece, they will do a lot more around monitoring the design, implementation and test progress on that performance axis – this actually is not a good example because every component has to perform or else the whole system sucks. So a better example might be GUI design which only applies to those components that have a GUI, these teams will put extra process in place to ensure they have the best possible GUI design.

InfoQ: Do you see this changing the way you test software as well?

Agile development does impact test a lot, with a highly iterative process things change a lot, and change is very hard for the test team to track and deal with. For example, when last month's tests are all broken because of the amount of churn in the code this month. The best way to manage this is to break down the barriers between development and test. Early on the test team will be doing test infrastructure development, talking with development on the kinds of things they'll need to be testing and making sure they are ready to do that. This is really a development role for the test team. Later on in the project we'll have the devs doing test work to help make a dent in the test debt that has built up due to churn in the product. Breaking down the barriers also makes for a much healthier team – so there's a lot of side benefits to Agile that I see. 

InfoQ: For this project, would you say you focused more on automated or manual testing?

Both. There is a suite of automated tests included in the XML Notepad project that uses the Visual Studio Team System Unit Test project, which I love by the way. This is a methodical unit testing approach which finds lots of bugs in edge cases and so on, and you look at the "code coverage" report to see what you haven't thoroughly tested yet and so on. But we also did a number of "bug bashes" to get people really using it like a customer would and this finds a different set of bugs, more in the usability area, and we got a lot of feature suggestions which also helps us figure out if the product is "complete" from a feature set point of view.

InfoQ: Why did you decide to release the source code and design document?

The purpose of the project was to show folks how to use System.Xml features. You can only do so much with code snippets and samples. There's nothing like a real app to really show folks how it all hangs together. Of course, it doesn't hurt if that app is also a handy tool. I already have folks asking if they can integrate the canvas with a bigger tool they are working on – one of them was in the content publishing area. So to help these folks grock the source code, it also helps to give an overview of how the app works which is what the design doc attempts to do.