Agile in the beginning: the Microsoft Solutions Framework circa 1993

I recently presented MSF v4.0 (alpha) at TechReady 2, Microsoft's internal technical training event in Seattle. This is the first time I've shared a stage with Bill - but not at the same time ;o)

Microsoft has a long history with the Microsoft Solutions Framework (MSF), which started back in 1993 -- that's a 12 year heritage! There aren't many frameworks that can claim to have added value to the development process for over a decade. I've been involved with MSF since 1998.

There have been some comments on the newsgroups that Microsoft invented MSF in recent times to badge its version of Agile which is present in Visual Studio Team System (VSTS). In fact, the original MSF from 1993 contains many Agile-sounding principles.

My friend Clementino Mendonca located the original MSF v1.0 guidance and highlighted some statements it makes, for example about design documents -- or the lack of them. If you read Agile authors you will hear refreshing statements like "Produce no document unless it's need is immediate and significant". Elsewhere you can read pieces on Agile that ask questions like, "Why do people document?" which suggest that teams should produce "barely enough" design documentation.

Back in 1993, MSF v1.0 was saying something very similar:

Why No Design Document?
The customer is rarely the intended recipient of a design document.  There are generally two uses for design documents:

• For purposes of management and communication between Development team members.
• To aid in maintenance and enhancement after release.

For purposes of management and communication between Development team members, the need for formal design documents is established by the Development Manager with his/her development team.  At Microsoft, design documents are developed when they are needed and, when memos, meeting notes, and interface specs are sufficient, time is not spent writing formal design documents.  "When they are needed" might be:

• Starting a new product.
• When team members are new to the company or to each other.
• When the design issues are complex.
• When there are too many developers on the project to ensure adequate communication otherwise.

Realistically, many corporate development projects have all of these characteristics, and a Development Manager should consider carefully a decision not to build design documents at some level.

For purposes of maintenance and enhancement after release, the best answer is to have self-documenting code and to generate any supplemental documentation automatically from the code itself.  Of course, interface and call diagrams are often indispensable.  A development manager should consider allocating time late in the development cycle if up-front design documentation is not critical.

extract from Microsoft Solutions Framework v1.0 - Solutions Development Discipline, 1993

So it seems that "agile thinking" isn't new: it's a bunch of good ideas, expressed in MSF and elsewhere. It would be interesting to trace the origins of the daily build and other good dev team practices. Who did it first?

This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at


Comments (2)

  1. Sam Gentile says:

    I wonder if either you are joking or this is a troll? You think Agile is about minimal documentation?

  2. It would be interesting to trace the origins

    > of the daily build and other good dev team

    > practices. Who did it first?

    Tracing the origin of the daily build would only to glorify an accomplishment that’s as relevant today as impressive today as an under-sea telegraph cable in the age of hand-held satellite communications.

    VST-F shipped without continuous integration in the box. The unit testing framework doesn’t allow for abstract test base classes. We had to fight to get test-first programming mentioned in MSF Agile.

    It’s the analog of the under-sea telegraph cable that Microsoft is trying to sell as an Agile toolkit and methodology. MSF Agile is Agile mostly in name (though not entirely), and VSTS fits an Agile developer like horse shoes might fit a greyhound.

    When Microsoft itself becomes a recognized practitioner of Agile practices, it will have a much better chance of actually creating tools for Agile development that are built with an understanding of the needs of tooling for Agile development.

    Until then, I suppose it’s fair to allow Softies to bask in the glory of antiquated past accomplishments like the daily build.

Skip to main content