As Simple As Possible, But No Simpler

As Simple As Possible, But No Simpler

Sam Guckenheimer, Group Product Planner, Visual Studio Team System, Microsoft Corporation

A Centennial Shift

2005 marks the centennial of Einstein’s publication of the Theory of Special Relativity. Einstein’s work not only settled forty years of debate on the nature of time and synchronicity, but largely set the agenda for much of science, technology, and world affairs for the 20th century. According to most popular legends, Einstein was a solitary theoretician, who discovered relativity in nearly monastic isolation, despite the distractions of his day job reviewing patent applications.

The popular view of Einstein is quite incomplete. Contrary to the popular image, Einstein was very concerned with the inventions he reviewed at the patent office, the majority of which concerned the synchronization of time for multiple practical purposes: industrial (railroads and maritime navigation), technical (coordination of clocks over distance), and political (territorial boundaries).

The culmination of this multidisciplinary interplay was the theory of special relativity. Once in a great while a scientific-technological shift occurs that cannot be understood in the cleanly separated domains of technology, science, or philosophy. ¹

A shift similar to the contrasting views of physics 100 years ago is occurring today in software development. 2005 also marks forty years of debate about software development methodology and process, much of which is chronicled in the September 2004 issue of Software Development. During that time, software development process has been described largely as though it were a “pure” pursuit, independent of the tools and technology that implement it. According to most viewpoints, process has been treated as an exercise for managers, specialist Program Management Offices and skilled practitioners, who could define metrics and activities quite divorced from the tools used to implement them.

Two general methodology factions have emerged. Software process, according to the traditional plan-driven view, is about prescribed artifacts and activities that measure intermediate progress toward a goal. This style has been easily caricatured by the Agile Community as unwanted overhead, creating as much harm as good. The Agile Manifesto² drew a sharp contrast between the two viewpoints. Yet neither version is complete.

A Different Approach

Microsoft Visual Studio 2005 Team System takes a different approach, with a big simplifying assumption. The major impedance to process adoption is simply the lack of integration of process and development tools, requiring process enforcement to be a set of purely manual tasks. Once the tooling automates the process guidance and the collection of metrics, then most of the overhead associated with process, and most of the resistance to compliance, will disappear.

Visual Studio Team System extends the concept of an Integrated Development Environment to an Integrated Services Environment for the extended software team – project managers, architects, and testers, as well as developers. Central to Team System is the integration of the tools with the workflow of Microsoft Solutions Framework, a knowledge base of process guidance, based on proven practices. This integration allows Team System to tailor the experience to the individual person and current activity, surfacing the right guidance to the right person at the right time.

Work Is Work

It’s no secret that most software projects have a hard time managing work effectively. Two big obstacles are the scattered sources of information everyone needs to access (requirements docs, specs, bug lists, task lists, etc.), and the changing perceptions of the (usually long list of ) stakeholders that make whatever information you find obsolete, once you find it.

Scrum (one of the agile processes) popularized a key innovation that removes these obstacles by the creation of a single Product Backlog. Here’s how Scrum defines it:

Product Backlog is an evolving, prioritized queue of business and technical functionality that needs to be developed into a system. The Product Backlog represents everything that anyone interested in the product or process has thought is needed or would be a good idea in the product. It is a list of all features, functions, technologies, enhancements and bug fixes that constitute the changes that will be made to the product for future releases. Anything that represents work to be done on the product is included in Product Backlog.³

Team System uses a common product backlog to track all planned, active, and completed work for the team and a history of all actions taken and decisions made regarding that work. It calls these units “work items”, and lets the user view and edit them in a database view inside Visual Studio, in Microsoft Excel, and in Microsoft Project, all the while synchronizing them to a common database.

One database behind the common, familiar tools de-fragments the information. Instead of cutting and pasting among randomly distributed artifacts, project managers, business analysts, developers, and testers all see the same work, whether planned in advance or scheduled on the fly, and whether from well understood requirements or discovered while fixing a bug.

Instrument Daily Activities

All project managers rely on data. In the simple cases, project managers track planned and completed activities (or activities reported completed) and bug rates. Often that’s all they have. In this case, the project plans and bug charts take on mystical meaning. Amazingly over time, the bug curves conform to expectation far more than they reveal differences in the underlying quality that the charts are supposed to measure.

On the other hand, very formal, plan-driven processes, such as TSP/PSP, rely on extensive data frameworks to collect size, quality, and effort at an extremely granular level, down to the fractional hour. The data collection requires tremendous rigor, and the correlation of the data into statistical databases is a considerable exercise. This disciplined attention to the bookkeeping is rarely sustained in practice.

The irony is that the vast majority of the data that a team needs is directly correlated to other actions that are already managed by software. Developers check in code, builds parse that code, testers write and run tests, and all their activities are tracked somewhere – in Project, Excel, the bug database, or timesheets. What if you could gather all that data automatically, correlate it, and use it to measure the process?

Team System takes that approach. It instruments the daily activities of the team members to collect process data with no overhead. Every time a developer checks in, a build runs, a test executes, or a work item is updated, Team System keeps track. It populates a data warehouse with the metrics, correlates the dimensions, and surfaces OLAP reports on the process.

Simple Observations

Basic questions become easy to answer. Is the project coming in on time, or how far off is it? How much has the plan changed? Who’s over or under and needs to have work rebalanced? What rates should we use to estimate remaining work? How effective are our tests? These are basic questions most project managers would love to answer with hard data. Once the data collection is automated, the answers become straightforward.

Project “Smells”

More significantly, most project managers would love to find blind spots – places where data indicate a likely problem. Martin Fowler coined the term “smells” for these suspicious areas of code; the parental analogy is as apt for the project as a whole. Imagine a graph that showed you these bug and test pass rates:

What would you conclude? Probably that the Instore Pickup Kiosk code is in great shape, and that you should look for problems elsewhere.

Now consider this graph, that overlays code churn and code coverage from testing on the same axes.

Suddenly the picture is reversed. There’s really high code churn in Instore Pickup Kiosk and the code is not being covered by the tests that supposedly exercise that component. Hmmm, maybe we have stale tests that aren’t exercising the new functionality. Could that be why they’re passing and not covering the actual code in this component?

Rightsizing the Process

No one process fits all projects. The central tension in selecting and applying a software development process is the balance between individual productivity and team predictability. Too little process may allow high productivity, but at the expense of low predictability. Too much process may ensure predictability, but at a severe cost in productivity.

Diversity compounds the problem. Regulatory environment, business risk, business upside, technology risk, team skills, geographic distribution and project size all play a role in determining the right fit of process to a project. Unfortunately, few methodologies and fewer tools can adapt well to these contexts. Methodologies that require manual enforcement have very high maintenance costs, notably in documentation, training and management. Tools do what they do, with limited ability to adapt to methodology changes or contextual realities.

Team System takes a different approach. Each project can choose its process, determining not only guidance, but workflow, policies, templates, reports, and permissions. There are standard agile and plan-driven process models for Microsoft Solutions Framework (MSF) built into Team System. There will also be a community of process extensions, some from Microsoft partners, and some from customers.

In both the agile and formal instances of MSF, its smooth integration in Team System supports rapid iterative development with continuous learning and refinement. A common work item database and metrics warehouse make it possible to answer questions on project health in real time. And the coupling of process guidance to tools makes it possible to deliver the right content to the right person at the right time.

Simplicity

Einstein reputedly said (although no one is quite sure), that a theory should be as simple as possible, but no simpler. Special Relativity is a notable example of his principle. Einstein was not the only one to propose a mathematical solution to the experimental data – the far more famous Henri Poincaré presented a different solution at the same time. Einstein’s, however, is remembered and taught in every physics class, while Poincaré’s is long forgotten. Why? Einstein’s is simpler -- his great insight was that properties of light required no conjectures about an “ether”, the medium of empty space that had preoccupied the 19th century.

Software development methodology has been prescribed, debated, debunked, reinvented, disputed, and theorized for forty years in a manner that has been largely disconnected from the tools that implement and automate it. This disconnect of process and tools has made the balance of productivity and predictability expensive and complex.

Some complexity will always exist. Software development is an intellectual, human pursuit, requiring complex interactions across a team. There will always be requirement, architectural, development and testing activities. Many of the work products surrounding these activities will differ over time, but the project manager’s fundamental questions will remain the same.

The team process, however, should reduce the complexity and provide trustworthy answers. By maintaining a single product backlog, instrumenting the daily activities, rightsizing the process, and automating the reporting, Visual Studio 2005 Team System removes the ether of unnecessary overhead. Team System makes the process as simple as possible, without making it simpler.

For further information on Microsoft Visual Studio 2005 Team System, see: https://msdn.microsoft.com/vstudio/teamsystem

For further information on Microsoft Solutions Framework, see: https://www.microsoft.com/msf

¹ Peter Galison, Einstein’s Clocks, Poincare’s Maps (Norton, 2003), p.40

² https://www.agilemanifesto.org/

³ Ken Schwaber & Mike Beedle, Agile Software Development with SCRUM, 2002, pp. 32-33.