http://en.wikipedia.org/wiki/Technical_debt

http://martinfowler.com/bliki/TechnicalDebt.html

http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

http://www.construx.com/10x_Software_Development/Technical_Debt/

http://www.ontechnicaldebt.com/

http://www.slideshare.net/intechnica/technical-debt-101

https://www.youtube.com/watch?v=ZUYIFLfyxoI

Anyone know of others that would be worth looking at?

Code Lens for Git "Team Activity View"

Filter link types on Code Map

CodeLens in Visual Studio Online enabled as a Limited CTP

We’ll be blogging some more about other Code Map features over the next few days. You can also check out these videos (yes it’s me doing the presenting):

https://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/717 (CodeLens)

https://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/213 (Code Map)

And finally, though not something built by my team, I’m personally really pleased to see Support for debugging lambda expressions with Visual Studio 2015.

The article explores Kanban and how it differs from other agile approaches such as Scrum.

My experience with scrum was as follows. You peel off a set of stories from the backlog to deliver in that sprint. Because you have a fixed-timebox there is pressure to make the stories quite fine-grained so you can be sure that they’ll fit in the time box, and you don’t have fractions of stories assigned to the sprint. You try and identify a theme to provide a common goal, but that can be a bit artificial, and some of the stories don’t really fit with it. Inevitably you are too greedy and as the end of the sprint draws near everyone feels under pressure to complete stuff, quality goes down, and then there’s a long tale of testing that ends up being done in the next sprint. Often the testing can’t be done anyway because you’ve got to wait for other stories to be completed before you have enough of an e2e experience to test (there’s only so much that can be achieved through unit testing). You try to write stories that are customer facing, but as they are quite fine-grained, this can be a bit of a struggle – stories creep in for backend and engineering work. You have trouble explaining the backlog to your stakeholders because the stories are too fine-grained to see the wood from the trees, and they are also not all customer-facing.

In order to cure these problems, we started evolving towards a Kanban approach, beginning by adopting the notion of Minimal Marketable Feature or MMF. An MMF is in the Goldilocks zone of granularity – neither too big nor too small, just right. There is a beautiful tension between making the feature marketable yet keeping it minimal, and a lot of hard work goes into designing the backlog and getting this right, as it should. We still have stories – they are used to break down the work to deliver an MMF, and we still try to make them customer-facing to keep the team thinking that way but don’t force it.

MMFs are marketable, so it became easier to communicate with stakeholders about the functionality being delivered and how it contributes to the business.

Execution focus turned away from the sprint to the MMF. When is the MMF expected to ship? Is the burndown of stories/tasks for that MMF tracking to that expected date? If not, what’s blocking, can the block be removed? Or is it that it’s just taking longer and expectations need to be reset with stakeholders? Do we need to shift effort from another MMF being done in parallel to one MMF to ensure that at least one gets completed ready for the next release? How is a release (= set of MMFs) tracking? Will all the MMFs make it (not too much of a disaster if they don’t, because all MMFs are designed to be self-contained, marketable in their own right)?

We found that a Kanban board of MMFs is quite an effective way of tracking progress. Focus shifts towards pushing an MMF across the board as quickly as possible, and lining up MMFs in the queue to feed the continuous delivery pipeline. There is no pressure to finish it against some arbitrary deadline (end of sprint); instead the team pushes itself to get MMFs through the system as fast as possible, though without skimping on quality and in a way that is sustainable long-term: late nights and productivity-sapping long hours are avoided as much as possible.

We have continued using sprints, but they’ve been demoted to useful planning checkpoints where an engineering team can re-evaluate it’s capacity, communicate with stakeholders about MMFs that have been completed since the last checkpoint, update expectations about when MMFs in flight are likely to finish, and raise awareness of what’s coming next in the queue. There is no longer a need to identify a theme for a group of stories in a sprint, because the MMF is the theme – all stories required to build it are naturally grouped.

I wouldn’t go back to Scrum.

Upcoming Changes in Visual Studio Architecture and Design Tools

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:

1. Understand code change at scale: CodeLens(TM) collaboration indicators and service for Team Foundation Version Control (TFVC)
2. Understand code structure at scale: code map, debugger map, dependency graphs, reverse engineering to UML tools
3. Validate code structure at scale: layer designer
4. Generate code at scale: DSL tools, code generation from UML models

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:

• Improving the experience for filtering and hiding nodes and (especially) links, to reduce clutter and noise when working with maps at scale;
• Making it easier to create "standard" maps, to take some of the guesswork out of creating maps that are useful for certain kinds of task including, for example: the full inheritance/implements graph for a namespace or keyed off a select set of types, the graph of all code that code be impacted by a change to an interface, the override hierarchy keyed off a method, and so on;
• Creation of maps across code for whole systems, not just code for individual components or which can wholly be contained within a single Visual Studio solution;
• Understanding systems comprising services, devices apps and web clients, making use of REST and dependency injection;
• Using non-diagrammatic ways to explore and understand code structure where that is appropriate.

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.

The body of the post actually reads:

Various Microsoft attempts at MDD have failed or been put on the back burner: WhiteHorse, Software Factories, Oslo.

Does Microsoft have any strategy for Model Driven Development? Will any of the forementioned tools ever see the light of day?

First we need to clarify some definitions. I distinguish between the following:

Model-assisted development, where models are used to help with development but are not the prime artefacts – they don’t contribute in any direct way to the executing code. Examples would be verifying or validating code against models or even just using models to think through or communicate designs. UML is often used for the latter.

Model-driven development, where models are the prime artefacts, with large parts of the executing code generated from them. Custom, hand-written code is used to complete the functionality of the software, filling in those parts which are not represented in the model.

Model-centric development, where models are the prime artefacts, but interpreted directly by the runtime. Custom, hand-written code is used to complete the functionality, with an API provided to access model data and talk to the runtime as necessary.

These are not separated approaches, and development projects may use a combination of all three. In fact, I imagine a continuous dial that ranges from model-assisted development through to model-centric development, such as the one illustrated below (starting at the left, the first five tabs are examples of model-assisted development).

The challenge is to make the movement through the dial as seamless and integrated as possible, and also to make sure that these approaches can be adopted incrementally and in a way that integrates with mainstream development (agile) practices. Only then will we be able to unlock the potential productivity benefits of these approaches for the broader development community.

In Microsoft, there are a number of shipping products which support or employ one or more of these approaches.

In Visual Studio, we have DSL Tools and T4, which together support model-driven development. New functionality was added to both in VS2010, and T4, for template-based code generation, continues to see broader adoption, for example in the ASP .Net community as evidenced by this blog post. for example. Many customers use DSL Tools for their own internal projects, and we continually get questions on this forum and through other channels on this.

Visual Studio 2010 edition introduced a set of architecture tools: a set of UML Tools (built using DSL Tools), a tool for visualizing dependencies between code as graphs, and a tool for validating expected dependencies between different software components (layers). I would place all these tools under the category of model-assisted development, although the VS2010 feature pack 2 does provide some support for generating code from UML models, which allows these tools to be used for model-driven development, if MDD with UML is your thing.

Visual Studio LightSwitch combines a model-driven (generates code) and model-centric (directly interprets the model) approach to the development of business applications. It is a great example of how models can really make the developer more productive.

Outside of Visual Studio, the Dynamix line of products, also take a combined model-centric/model-driven approach to the domains of ERP and CRM business applications. For example, take a look at this blog post.

I am an architect with the Visual Studio Ultimate team, who are responsible for DSL Tools, T4, and the architecture tools. In that team, we are now looking into how to take these tools forward, focused very much on how to make software developers and testers more productive. Part of this will be to consolidate and integrate some of what we already have, as well as integrate better with other parts of Visual Studio and mainstream development practices. Another part will be to add new features and capabilities and target support on specific frameworks and domains – as LightSwitch does. We’re focused on addressing the challenge set out above, and to deliver value incrementally.

As we start to deliver the next wave of tools, I look forward to a continued conversation with our customers about the direction we’re headed.

Addendum (8/4/2011): I forgot to mention that another problem we’re currently focused on is how deliver a much more seamless integration between models and code, which is essential to meet the challenge described above.