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. 1
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 Manifesto2 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.
1 Peter Galison, Einstein’s Clocks, Poincare’s Maps (Norton, 2003), p.40