What is 'Progression'?

I've been working on Progression for the past 2 years, but there's not a very good definition that's been made public about it.  Let me attempt to describe the feature here.  It's been talked about in a few different ways by Cameron Skinner in his blog and on stage at Tech*Ed as well as some videos on Channel 9, but let me try to give a complete description here.

Why the name 'Progression'?

First the name 'Progression'.  Progression attempts to aid in the evolution of software, hence the name 'Progression'.  It's kind of a code-name, but more than that when you think about how software progresses over time.  These tools aim to aid in the discovery of how software progresses and aid in the decision making that developers and architects make to advance (i.e. progress) their software in the future.

At it's heart Progression is a directed graph.  The directed graph is very flexible in that it simply contains Nodes and Links (vertices and edges in some nomenclature).  Graphs can be used to depict just about any kind of relationship between Nodes.  It's the classification of the Nodes and Links that give the graph some meaning.  Graphs can contain nodes for people, animals, pharmaceuticals, institutions, families, species, geographies, planets, molecules, etc.  When it comes to understanding a conceptual model of software a graph might contains nodes for computers, applications, assemblies, classes, methods, files, projects, solutions, etc.  Graphs can contain links for relationships between the nodes.  In the case of people, links can be used to indicate relationships such as parent/child, manager/employee, coworkers, neighbors, etc.  In sociology these relationships between people are the basis for the science of groups of people.  For software, graphs can contain links for relationships such as Contains (assembly contains a class, for instance, or class contain a method), calls (method calls method, for instance), references (for assemblies that reference another assembly and therefore need that assembly to be available at load-time).  Progression attempts to bring the science of networks to software itself.

Progression collects and manages such data about software projects.  Now one of the really cool things about Progression is that it isn't limited to software.  Under the covers it could manipulate any kind of directed graph (like a social network described above).  But the team creating Progression isn't just passionate about directed graphs, we're really excited to solve certain software development challenges.  So the sweet spot for the features in Progression is all about software.

Progression provides some user interface elements to expose this data to developers and architects in a way that they can use to help them solve software development problems. 

What are some of the problems that Progression allows the developer/architect to solve?  

First is Architectural Discovery.  This is the concept where a developer is introduced to a new code base and needs to understand how it works under the covers.  Progression provides many different ways to display and explore the data in the graph of code, assemblies, classes, methods, etc.  It's the visualization of these elements that allows the developer to see a big picture and dive into details in order to learn how things related and work together (hopefully well, but sometimes not very well at all!).

The second problems that Progression solves is allowing the user to browse rich unending data.  Directed graphs can have cycles.  Directed graphs can also be used to hold just about any kind of data.  Progression provides a tool to browse such information in a tabular way that allows expansing and navigation even in the face of cycles and data that seemingly never ends.  We've done a lot of work to enable this kind of flexibility in a general purpose tool.

With these tools one can answer questions like: What are my unused pieces of code?  What are the cyclic dependencies in my code?  What are the important hubs in my system?

Real software, not slide-ware

Progression isn't very interested in simply documenting the architecture of a system as a communications mechanism.  There are plenty of documents, modeling languages, power-point and visio features that can be used to draw a model of a system.  They all can be used without any code at all being in existence.  These things can be really useful, but that's not what Progression is about.  Progression, instead, conveys the actual software architecture based on reverse engineering binaries and sniffing out code as it's being written.  It works very deeply with the Visual Studio development environment and the CLR/.Net Framework to get the information it conveys.  As such it's a reflection of the actual code, not a conceptual model that gets stale quickly after coding begins.  Used in conjunction with modeling tools, Progression provides the linkage to actual implementation to verify the implementation against the conceptual design.  This provides an 'as-is' versus 'to-be' kind of question.  Wouldn't it be awesome if you could walk up to an implementation and design document and have a tool that tells you where the implementation and the intended design differ.  That's what Progression enables.  In this first version (VS 2010) we're just scratching the surface.  We've got some amazing capabilities that we'll deliver in coming releases.

You should stay tuned to try out VS 2010 Beta2 in order to see if Progression (and a lot of other cool features) can help you with these kinds of questions.

I'll provide more details in the future.