Stuart Kent - Building developer tools at Microsoft - @sjhkent
In case you missed in my recent post about Code @ Scale, Mathew Aniyan has just blogged about the CodeLens incoming changes indicator, an enhancement to CodeLens collaboration indicators that we're shipping in Visual Studio Update 2. This helps the developer see changes in other branches that could impact the code they are currently working on. Try it out and let us have your feedback.
As customers you may not be that interested about how we are internally organized to deliver the tools and services in Visual Studio, TFS and Visual Studio Online. However, it helps to have a little of that background to understand why individuals focus on the topics they do. So, given that I have been quiet so long, I thought I'd say a little about what I and my team are working on just now.
I've recently changed role, still in the realm of developer tools, but now leading a team focusing on tools and services to help developers understand, maintain and evolve code at scale. The team is split between the UK and India, with one of the team also based in France - we're very familiar with distributed working across timezones and geographies. Before this role, I was worked with the team that is now delivering Application Insights, so expect some occasional articles about that.
The starting point for code at scale comprises the following existing tools and services, which I've grouped under four high level areas:
For the moment, our main push with (1) is to enhance the overall experience (see e.g. Mathew's blog post on the upcoming CodeLens(TM) Incoming Changes Indicator) and extend CodeLens(TM) support for other VC systems, starting with Git and TFVC in VS Online (the service only works with TFS on premise at the moment). We are also looking to add support for other languages.
On (2), we are currently focusing our efforts around code map and debugger map. For code map, we are looking at:
Debugger map is actually a code map, whose population is driven from a debugging session, whether that be live debugging or debugging through an IntelliTrace log. As such it will benefit from some of the enhancements to code map. However, we are also looking at a set of improvements which are specific to the debugging experience. In particular, we have worked with the diagnostics team to improve the experience of using code map with IntelliTrace, with the first results of that collaboration appearing in Visual Studio 2013 Update 2 CTP2.
On (3), we get consistent feedback from customers about the value proposition behind the layer designer, but are also aware of some the limitations of the current tool. To that end, our focus will be on converging the layer designer and code map experience, enabling layer validation at scale - beyond the bounds of a single VS solution, and enabling a richer set of architecture validation rules to be defined.
We are currently considering how best to take (4) forward.
As always we can't announce timings and plans are always likely to change, especially as we learn more via telemetry from how customers are using the product, and through informal feedback from customers about the tools and problems that are most important to them. To that end, if you have feedback/questions about your usage of the tools, or about any of the ideas described above, please get in contact, e.g. via a comment on this blog.