MVVM is a central concept in WPF, Silverlight, WindowsPhone and Windows 8 development, so I decided to take some time and bubble up some of the content in the WPF MVVM Toolkit, which we created some time ago.

Model-View separation is by no means a novel idea in the software engineering industry—the idea has been around for at least 25 years. In the past few years, there has been a lot of interest in model-view architectures, fuelled both by the growing complexity of modern software systems and by the necessity to display UI on various devices, while reusing the same underlying business logic.

This post outlines the benefits of model-view separation. It is essentially the same content as the content included in Part 1 of the documentation, which goes with the WPF MVVM Toolkit.

1. Introduction to the Model-View-X Paradigm

A well-designed application is an application that is easy to develop, test, maintain, and evolve. Creating such an application typically involves some form of separation and encapsulation of responsibilities. A common approach involves separation of the UI (the views) from the business logic (the model). In fact, that approach is so common that there are a number of stock solutions, collectively known as the model-view design patterns:

• Model-View-Controller (MVC) is the granddaddy of them all, dating back to 1979. In MVC, the Controller creates the Views and the Model. The Views register with the Controller, which also has a reference to the Model. A View notifies the Controller of user interactions, and the Controller in turn queries the View for its state and updates the Model appropriately. The Controller notifies the Views when there are changes in the Model, and the Views query the controller to update their states.
  
  
• Model-View-ViewModel (MVVM) is a derivative of MVC that takes advantage of particular strengths of the Windows Presentation Foundation (WPF) architecture to separate the Model and the View by introducing an abstract layer between them: a “Model of the View,” or ViewModel. The pattern was first introduced by John Gossman – the architect on the Blend/WPF/Silverlight team – and derives from the Smalltalk ApplicationModel pattern, as does the PresentationModel pattern described by Martin Fowler. It was first utilized by the Expression team (John was part of that team at the time) as they developed version 1 of Expression Blend. Without the WPF/Silverlight-specific aspects, the Model-View-ViewModel pattern is identical to PresentationModel.
  
  In MVVM, the View and the ViewModel are typically instantiated by the container application. The View keeps a reference to the ViewModel. The ViewModel exposes commands and observable entities (“bindables”) that the View binds to (or to put it in programming terms, view.DataContext = viewModel;). User interactions with the View trigger commands on the ViewModel, and updates in the ViewModel are propagated to the View through data binding.

2. Justification

2.1. Simplistic Application Design

To demonstrate the use of the Model-View-X architecture, let’s consider a simple contacts application. The application has two windows (views): a table view, where you can see all entries in the contact book in a table, and a record view, where you can see individual records.

Fig. 1 UI of the contacts application

The Model-View separation for this particular problem feels natural, where the Model is the contact book and the Views are the two windows shown in Figure 1. So the trivial design (which is a two-tier Model-View-only design) would look as shown on Figure 2.

Fig. 2 Simplistic application design – the views are directly connected to the model

As shown, ContactBook keeps a list of views (which are added and removed with AttachView and DetachView). When a contact changes, ContactBook notifies all views by calling their Update methods, and all views update themselves by calling the model's GetContacts method. Upon instantiation, RecordView and TableView are given a reference to ContactBook, which they keep as a field (contactBook).

Notice how the two views are tightly coupled with the ContactBook class. Addition of business logic would only increase the level of coupling.

2.2. Simplistic Application Design – WPF/Silverlight Version

Before examining the design further, let’s convert the design to a WPF/Silverlight-friendly design. WPF/Silverlight provides the following native facilities that can be utilized directly:

• Databinding is the ability to bind UI elements to any data.
• Commands provide the ability to notify the underlying data of changes in the UI.

Using these facilities, the WPF/Silverlight-friendly design is changed as follows:

Fig. 3 WPF/Silverlight-friendly simplistic application design

In the modified design in Figure 3, the views derive from UserControl (there is no need for an abstract View class) and ContactBook no longer needs to maintain a list of views—ContactBook no longer needs to know about the views. Instead, the views point to ContactBook as their DataContext and use WPF data-binding to bind to the list of contacts.

You will also notice that List<Contact> has been replaced with ObservableCollection<Contact> to allow the views to bind to the ContactBook using WPF data-binding mechanisms.

Notice how WPF’s data-binding mechanism allows us to create a much more a loosely coupled design (at least until further addition of business logic).

2.3. Problems with the Simplistic Design

Things get more complicated if we introduce the following new functionality:

1. Track the selected item, so that we update RecordView whenever the selection in TableView changes, and vice versa.
2. Enable or disable parts of the UI of RecordView and TableView based on some rule (for example, highlight any entry that has an e-mail in the live.com domain).

Feature (a) can be implemented by adding a CurrentEntry property directly in ContactBook. This solution breaks down, however, if you have more than one instance of the UI connected to the same ContactBook. Feature (b) can be implemented in the views (RecordView and TableView). The problem if we do that, however, is that if we want to change the rule, then we would need to change both views.

Gradually it becomes apparent that we need a third layer in our application. We need a layer between the views and ContactBook that stores state shared by the views. We need a meta-view of sorts.

2.4. Enter Model-View-ViewModel (MVVM)

A ViewModel can serve as the third layer, providing an abstraction that acts as a meta-view (a model of a view), storing state and policy that are shared by a group of views. By introducing the concept of a ViewModel, our design changes to the following:

Fig. 4 Application design using a ViewModel

In this design, the views know of the ViewModel and bind to its data, to be able to reflect any changes in it. The ViewModel has no reference to the views—it holds only a reference to the model.

For the views, the ViewModel acts both as a façade to the model, but also as a way to share state between views (selectedContacts in the example). In addition, the ViewModel often exposes commands that the views can bind to and trigger.This use of commands is covered in the next section.

2.5. The use of commanding in MVVM Applications

WPF and Silverlight introduce a new input programming mechanism: commanding. Commands allow loose coupling between the origin and the handling of an action. Multiple sources can invoke the same command, and the same command can be handled differently depending on the target. All commands implement the ICommand interface.

For UI actions, WPF provides a specialized RoutedCommand class. A RoutedCommand is routed through the UI element tree, so the target of a RoutedCommand must be part of the UI element tree. In MVVM designs, however, command targets are often implemented in the ViewModels, which in turn are not typically part of the UI element tree. This requires the introduction of a different kind of command—the DelegateCommand—that implements ICommand and can have non-UI elements as its target.

Fig. 5 Application design using a ViewModel, exposing bindable commands

The DelegateCommand construct was originally introduced during the development of Microsoft Expression Blend version 1. A generic version of DelegateCommand was later released as part of the Composite Application Guidance for WPF on MSDN. Note that some MVVM sources refer to the same construct as RelayCommand.

A DelegateCommand is an ICommand that allows the views to bind to the ViewModel. Even though the diagram above does not show this explicitly, all ICommands exposed by the ViewModel are DelegateCommands. For example, the code for the AddContactCommand in the ViewModel may look as follows:

3. Benefits and Consequences of Using MVVM

The benefits of MVVM are the following:

• A ViewModel provides a single store for presentation policy and state, thus improving the reusability of the Model (by decoupling it from the Views) and the replaceability of the Views (by removing specific presentation policy from them).
• The Model-View-ViewModel design improves the overall testability of the application. One can easily create unit tests that target the Model and the ViewModel layers. The MVVM design also improves the “mockability” of the application, by allowing easy run-time simulation of the tiers, which is crucial to testing complex software products.
• The Model-View-ViewModel design is a very loosely coupled design. The View holds a reference to the ViewModel, and the ViewModel holds a reference to the Model. The rest is done by the data-binding and commanding infrastructure of WPF.

The consequences of MVVM are the following:

• The typical relationship between a ViewModel and the corresponding Views is one-to-many, but there are also situations where that is not necessarily true. In general, any business logic and input-handling business logic (selection tracking, and so on) is kept in the ViewModel.
• There are situations when one ViewModel is aware of another ViewModel within the same application. Such situations arise when there is a master-subordinate relationship between two ViewModels or when a ViewModel represents a single item (for example, the visual representation state of a single contact). When this happens, one ViewModel can represent a collection of ViewModels. Such a case in demonstrated in the 2nd part of documentation that comes with the WPF MVVM Toolkit.

4. Next Steps and References

Hopefully this post provides a simple introduction to the pattern. As a next step, download the WPF MVVM Toolkit, review the walk-through and the provided code and go write some apps.

It is important to note that there are a number of other (more full-featured) MVVM toolkits out there. Perhaps the most popular one is Laurent Bugnion’s MVVM Light, but there are many others on Codeplex. You should be using those for your WPF / Silverlight / Windows Phone and Windows 8 applications. Here are a few additional references that may help too:

• Presentation Model by Martin Fowler, July 2004.
• Introduction to Model/View/ViewModel pattern for building WPF apps by John Gossman, October 2005.
• Separated Presentation by Martin Fowler, June 2006.
• WPF Patterns by Bryan Likes, September 2006.
• WPF patterns: MVC, MVP or MVVM or…? by the Orbifold, December 2006.
• Model-see, Model-do, and the Poo is Optional by Mike Hillberg, May 2008.
• PRISM: Patterns for Building Composite Applications with WPF by Glenn Block, September 2008.
• The ViewModel Pattern by David Hill, January 2009.
• WPF Apps with the Model-View-ViewModel Design Pattern by Josh Smith, February 2009.

• Principles 1: The Essence of Driving – A Crash Course in Project Management
• Principles 2: Principles of Software Testing
• Principles 3: Principles of Software Development
• Principles 4: End-to-End Development Process
• Principles 5: End-to-End Development Process   (for Large Projects)

+++

This fifth post discusses and end-to-end development process for large software projects.

The only difference between large and small projects is that large projects require more “supporting infrastructure” (more processes, etc.) than small projects, due to the fundamentally imperfect communication between the team members. The “supporting infrastructure” is a tax we have to pay when we develop software. We can minimize it, but we can never really avoid it completely.

Larger projects require larger teams, which (due to accumulated communication imperfections) require larger process tax.

On one hand, we like short product cycles, because they get the product out in the market quickly; on another hand, the shorter the cycle, the higher the ratio between process tax and actual productive time. This is a classic case of an optimization problem, which can be defined as…

“Find the shortest possible project cycle, that keeps the process tax at a reasonably low level“.

Clearly, there’s a variety of other factors that we need to consider when we talk about project and product cycles. To list a few, we need to factor in the general product business model, pre-existing contractual obligations, specific calendar events such as conferences or trade shows, the competitive landscape, etc. For the purpose of this article we can assume that all of these additional factors have already been taken into consideration.

Single Project Rhythm

I am a big believer in having a single, transparent, well-socialized and strictly enforced project rhythm. All products that an organization delivers in my opinion should be aligned to this single rhythm.  The rhythm (or cycle) should be short enough, so that it can accommodate all products in development. In this model, different products can take different number of cycles. At the end of every cycle, one or more products get released.

Having a single cycle in my opinion dramatically decreases the complexity (and ultimately the process tax) that a team has to pay. It helps create well-aligned, synchronized and cohesive organizations, reduces dramatically the release management costs of a product, practically eliminates context switching for the individual engineers, drives ownership deep into the organization, improves communication with supporting disciplines (docs, localization, support, sustained engineering), and so on.

Agility

In this model, agility is achieved by having an appropriately-sized cycle. For example, for a desktop OS the right cycle may be 6 months or 12 months. In contrast, a web site would probably need to have a release valve every 2 to 4 weeks. Agility doesn’t mean lack of planning – agility means a reasonably short cycle capable of getting high quality products out in a predictable, controlled fashion.

Process Summary

The process of developing a large software project can be organized in 4 major phases (see Fig. 1 below):

1. MQ
2. Pre-planning and Planning
3. 1 or more Development Cycles
4. Stabilization and Release

(A) and (B) happen simultaneously. (A) is “Milestone for Quality” targeted at constructing a high-quality “software production factory”. This milestone gives the engineering organization a chance to optimize and simplify the tools and processes that it uses to product the product. (B) follows a predefined planning process. Planning is a whole other topic in itself. (C) consists of one or more close-looped development cycles.

Figure 1  Development Process Outline

Obviously this is just a general outline. The size of the different phases has to be determined by the development organization, based on deep understanding of what needs to happen in these phases and on the current state of the business and of the development factory. Some phases (specifically A and B) may shrink if there is no need for them.

Below I show an actual implementation of this general outline. Each small rectangle represents one week. Weeks in green are “stabilization weeks” (stabilization has different meaning for the different milestones – see tables below). Note again that the size of the actual milestones and phases that I show below are just a specific implementation of the general outline. You can have development cycles that are as short as a week, if you think that the ratio of dev time to process tax associated with managing every cycle is reasonable. You can also have longer cycles, although I personally wouldn’t recommend cycles that are significantly longer that 18 weeks or so.

Figure 2  Development Process - Detailed View

With these sizes we have…

• About 18 weeks (4 months) of pre-planning and planning activities.
• One or more dev cycles of 15 weeks (3.5 months)
• Final stabilization of 10 weeks (2.5 months)

I.e. a release with 1 dev cycle takes about 9.5 months; a release with 2 dev cycles takes about 13 months, etc.

The number of the actual development cycles can vary and is a purely business decision. At the end of every development cycle, the organization delivers shippable functionality. When management deems that the available payload makes sense as a next major version of the product, they switch the team to the RTM (RTW) phase, and drive to an actual release.

Before we delve in MQ, it’s important to note that all of these phases are divided in “red weeks” and “green weeks” (a block denotes a week). “Red weeks” are weeks of active development, “green weeks” are weeks of stabilization. Obviously the actual activities that happen in these weeks depend on the phase of the project.

MQ

MQ is the Quality Milestone. The role of MQ is ensuring that we have a working high-quality “production factory” before we embark on producing the next version of the product.

Figure 3  MQ and Planning

The breakdown of MQ is as follows:

Figure 4 Breakdown of MQ

MQ is all-inclusive collaborative effort between the 3 disciplines. The majority of PM, Dev and Test will be working on MQ activities during MQ. A few PMs and Devs will be working on planning / prototyping in parallel. MQ is planned and rigorously project-managed. MQ has a set of exit criteria that the org needs to hit before exiting the milestone.

The Dev Cycle

All features are developed during the dev cycle, which looks as follows:

Figure 5  Dev Cycle

There is a single prioritized feature backlog that captures all features that are being worked on in the current development cycle or can be worked on in future cycles. The list of features that comprise the current development cycle is stable throughout the cycle i.e. Management does not change the list beyond M0 – they have to wait for the next M0.

Any feature that cannot be completed is “cut” until the new dev cycle. Features that take more than one dev cycle to complete will be split into smaller manageable “featurettes” can be completed within the constraints of a dev cycle. Several featurettes may comprise the final feature. At the start of the development new cycle the feature is re-evaluated again against the other features in the backlog.

The start of every new dev cycle is a clean slate. All bugs and features are automatically “cut” and need to be reevaluated and brought back (can be evaluated and brought back during)

IMPORTANT: The development cycle is a contained unit of delivery of added value. We can have as many development cycles as necessary to build a compelling value for the “big release”, but every one of them ends with high quality features that are ready to ship.

The breakdown of the development cycle is as follows:

Figure 6  Breakdown of a Dev Cycle

The M0 to M4 cycle can be repeated multiple times within a release. Every time in M0 (but only in M0), executive management gets to redefine the feature backlog.

Stabilization and Release

The final phase in the development process (disregarding the various post-release activities for now) is the “Stabilization and Release” phase or “RTM”.

Figure 7  Stabilization and Release (“RTM”)

This phase is about fixing bugs, integration (if necessary) and managing the final quality of the release. The breakdown is as follows:

Figure 8  Breakdown of Stabilization and Release

QFEs (Hotfixes)

Every large software project needs to have a mechanism to deal with hotfixes (also known as QFEs). The nature of these fixes requires reactive delivery (as opposed to the proactive approach described above). Teams typically maintain a separate source code branch (or branches) for QFEs and that is typically the same as the branch that contains the currently shipping version of the software.

Due to their reactive nature QFEs are delivered on demand with a release schedule that looks as follows:

Figure 9  QFE Release and RI Schedule

Typically, fixes introduced in the QFE branch must make their way into the Main product branch, which is done with a series of regular reverse integrations (or RIs) as shows above. QFEs also get packaged as larger packages and released as service packs (or SPs).

Every QFE is subjected to a root-cause analysis, following a simple standard template, to help the team avoid similar situations in the future. 

Templates and Artifacts

Last but not least I wanted to provide a quick list with some of the fundamental documents that are required to bootstrap a development process for a larger product. Note that this list is nothing more than a reasonable starting point – at least according to me.

Figure 10  Key Templates and Artifacts

Conclusion

There are many ways to ship software products. Large products require more pampering and more scaffolding, at least until a critical mass of the team adopts a coherent product development culture. If you want to ship high quality products, you need to invest in rationalizing your product development cycle. The best way to do that is to plan, using a series of thought experiments (e.g. “imagine that we have achieved code complete, what are the steps from CC to release ready and how long are they realistically going to take”), and a guiding principle of lowest possible overhead costs and highest possible simplicity.

Like many of you I patiently waited for the February and March updates and just yesterday, at the end of April, I finally got prompted to install them. Unfortunately, as I hooked up the phone to my PC to update it, I hit error 800705B4.

Error code 800705B4 resolves to the following:

0:000> !error 800705B4 Error code:
(HRESULT) 0x800705b4 (2147943860) - This operation returned because the timeout period expired.

Since it took me a bit of digging to recover from it, I wanted to share here the fast way to overcoming this error:

1. Go to https://support.microsoft.com/kb/2530409 and download the Windows Phone Support Tool for your PC platform.
2. Follow the instructions in the tool. You won’t lose any of your information.
3. After the tool is done recovering your phone, hook it up to Zune again and get the update successfully.

Hopefully, that’ll save folks out there some time reading through MSDN docs.

• Starting with this release, we are moving all of the development of the library to Codeplex. We have also moved the solution to VS 2010;
• Jared Moore made several important modifications to our Fault Injection API, including but not limited to support for in-process fault injection, support for MethodInfo-based method identification, various performance improvements and bug fixes. In addition, we are releasing the complete source code of the unmanaged FaultInjectionEngine.dll, which now builds cleanly at warning level 4;
• Dennis Deng extended the Input Simulation API with support for injection of non-ASCII strings in Keyboard.Type(…). We have also added support for Mouse.DragTo(…);
• We have added support for 64-bit in our Leak Detection API;
• Andrey Arkharov extended the Object Comparison API with support for encoding and decoding object graphs from arbitrary streams, annotating object graph nodes with custom comparison strategies and type-specific object graph factories, together with several additional tests;
• We extended our String Generation API with support for string generation from regular expressions. We have also added a CommonRegularExpressions class, to speed up test development;
• We have added lots of additional tests, and have refactored the existing tests into namespaces for better discoverability.
• Last, but not least we have made some important API documentation improvements – the API documentation now sports namespace docs.

Check out the TestApi v0.6 release notes for a more detailed version of the above. Then let us know what you think and vote for features.

Update: Shortly after I posted this article, Peter Henry noted that he had a very similar article out already. Here is the link to it – it has good additional information – check it out: https://www.pchenry.com/Home/tabid/36/EntryID/389/Default.aspx

So you got your Windows Phone 7 device, you downloaded the free development tools and now you are itching to write your first “Hello World” app for WP7. You fire up VS 2010, create a quick phone app, connect your WP7 device to your development PC, select “Windows Phone 7 Device” as a target and attempt running your first app on your phone.

You will get the following message…

You have to make sure your device is ”developer unlocked” before you can deploy applications to it. Here’s how you unlock your device:

1. Connect your device to your PC through USB.
2. Start the Zune desktop software.
3. Start the “Windows Phone Developer Registration” software.

1. At this point, provided you have a developer account (which you get on https://developer.WindowsPhone.com) you can register your device. Once registered you’ll be able to use it for development purposes.

Easy! (not necessarily straightforward though :) )

As part of the move, I needed to set up a code review process. Turns out that it’s a bit of a struggle to figure out how to set up a simple CR process using standard tools – mostly due to poor documentation – so I thought I’d share what I did in this post. Hopefully, that will save someone out there some time.

Code Review Process

The general CR process goes as follows:

1. The developer creates a new shelveset (see the TFS documentation for a definition of “shelveset”) with his/her changes and sends the shelveset for CR.
2. The code reviewer performs the CR, sending back feedback.
3. The developer revises his/her code based on the CR feedback and generates a new shelveset.
4. Steps 1-3 get repeated until the code reviewer approves the code change for checkin.
5. The developer checks in the code.

The tools we use for CR are VS 2010 itself and WINDIFF. The latter is a diffing tool used for step 2 of the CR process.

Initial Setup

To set up WINDIFF as your diff-ing tool, in VS 2010 go to Tools > Options…, scroll down to the Source Control item and configure your compare tool to be WINDIFF as shown below:

Shelving

Shelving is the act of storing pending changes on the TFS server (see this link for more). To create a shelveset, in Source Control Explorer, right-click on the folder, containing all pending changes, and choose Shelve Pending Changes… in the displayed context menu. This will bring up a dialog that you can use to shelve your changes.

Once you shelve your proposed changes, send an email to the code reviewer, with your username and the name of your shelveset.

Unshelving, Diffing and Code Review

When you get a CR request, go to File > Source Control > Unshelve Pending Changes… and in the displayed Unshelve dialog, discover the shelveset that you need to review and click Details…

In the displayed Shelveset Details dialog, right click the file you want to review and compare it to its unmodified version. This will trigger WINDIFF as a comparison tool. Record your comments in an email and send them back to the developer (or approve the checkin if you agree to it).

Conclusion

That’s pretty much it. Obviously, this is a poor man’s solution, but it’s certainly better than nothing. There are a bunch of more advanced solutions out there providing code annotation, review workflows, etc. that you may find valuable too. This post by JB Brown may be a good starting point for those who want to go further.

• Principles 1: The Essence of Driving – A Crash Course in Project Management
• Principles 2: Principles of Software Testing
• Principles 3: Principles of Software Development
• Principles 4: End-to-End Development Process
• Principles 5: End-to-End Development Process (for Large Projects)

+++

This fourth post discusses an end-to-end development process. Obviously, there are many ways to develop software. While a lot of the basic principles apply almost universally, every sufficiently autonomous organization needs to figure out what works for itself, and then progressively refine it.

It is important to note that this process is the same process we used to manage several projects and has resulted in delivery of high-quality products, in a controlled manner, on time (actually ahead of time in a few cases). In other words, this is a real, proven process, not a theoretical construct.  I’ll actually show two versions of the process – a simple one - for smaller orgs, and a more involved one - for larger orgs.

Guiding Principles

Before going further, I want to once again reiterate the Principles of Software Development. These principles are the underlying “Constitution”. In summary, they are:

• Everybody on the team fully understands the plan.
• Deliver features in a gradual, close-looped manner.
• Define release criteria at the start of the cycle. Track visibly.
• Exercise defect prevention – whenever possible.
• Have a stable, fully-transparent, committed schedule from the start.
• No code while planning the “What”. No code without spec.
• Fully working and timed setup on day 1 of M0.
• Strict and reliable reverse- and forward-integration gates from day 1 of M0.
• Start together, work together, finish together.
• No work happens outside of the main development cycle.
• Every major system has an owner.

Goals

At the high level, we want to be able to produce high-quality, compelling software, in a well-organized, intentional, cost-effective, and predictable manner. In order to pull that off, we need the following:

1. Commitment, at all levels of the organization, to “do the right thing”. Full management sponsorship.
2. A well-designed organization;
3. A well-designed “business cycle”;
4. A well-designed development process;
5. A well-designed and working “engineering factory”;
6. A high-powered and high-morale team;

This post talks about “D”, but it goes without saying that “A” to “F” represent a system of connected vessels and need to be designed, implemented, and refined together.

This post also makes the assumption that you have a working “Planning Process” that generates compelling product value propositions. Clearly, without a compelling product that addresses a customer need, it doesn’t matter how excellent you are in delivery. There are various ways to plan a product. At Microsoft, we use a bunch of different approaches, with a lot of folks now gravitating towards the so called “Sinofsky model”. At any rate, this post does not discuss the planning process (I may do this in a future post).

In order to deliver a high-quality product, you need to plan and design before you code. On the other hand, you don’t want to get stuck in planning for a prolonged period of time, because time may erode the value prop of your product and because you need fast and frequent customer feedback – you may be working in the wrong direction. Clearly, we need to “marry” these two competing priorities and clearly this is an optimization problem. What follows is our solution to the optimization problem, but solutions will vary based on specific product, business, industry and team considerations. Treat this as a starting point – take it and make it your own.

Process 1 – Simple Projects

We used this simple version of the process to develop TestApi – the API library for test and tool developers. TestApi is a relatively small and simple project. With this process, we released five versions of the library and we released all of them on time or ahead of time.

The development schedule looks as follows:

Figure 1. Simple development schedule

The schedule consists of 5 major milestones:

• M0 – Planning – in this phase, we finalize the list of features we’d like to deliver in the release. Every feature has an owner. All owners understand the schedule. The necessary prototyping is done. At the end of M0 we have a backlog for the release, to which we have committed. Once we commit to the backlog. We do not allow feature creep after the end of M0.
• M1 – Design – in this phase every owner delivers a “conceptual document” that explains the usage of their feature accompanied if necessary by a design document. In the case of an API library such as TestApi, this is a API usage document and API design document.  The usage and design gets reviewed and approved by the Architecture review body (3 people in the case of TestApi). Once the design has been approved, the owner checks in the empty stubs (e.g. of the API) and the corresponding acceptance tests, together with an initial version of the XML documentation and gets stubs, tests and documentation to build cleanly. The documentation (both docs generated from XML comments as well as the conceptual documentation) gets sent to the Documentation team for editing. The Legal team (LCA) gets engaged.
• M2 – Implementation – in this phase, the owner implements the tests, code, fixes the documentation (based on editorial feedback from the Docs team) and drives to ZBB (zero bugs)
• M3 – LCA and Samples – in this phase the owner implements stand-alone samples (if applicable) and discussed the product with LCA (legal) if applicable. Legal signs off.
• M4 – Stabilization and Release – final stabilization, release checklist (we have a predefined checklist) and final release.
• Prep – At the end of every release cycle, we have about 4 weeks of “padding”. During that period, we do various post release activities (blogging, etc.), we invest in our engineering “factory” and we engage on preliminary planning for the next release (identifying possible participants, defining dates, etc.) This is a fairly relaxed period and that is by design.

All features associated with a release are tracked in a table similar to the TestApi Feature Backlog table presented in this post:

Figure 2. Feature readiness checklist

All source code is static analysis clean by default (FxCop, StyleCop, etc.) – checking in a violation results in a build break. There is a FAQ for commonly asked questions (e.g. “I can’t be done with a feature on time, what do I do?”, etc.) that evolves with every release.

As a general rule, the timelines above are rigorously adhered to. If you “fall off the train” (meaning – fail to meet a deadline), you don’t get back on the train until the next version (which is always no more than 3 months away, and of course you tend to deliver larger payload for it). We have a dedicated project manager who drives every release (for TestApi that was Alexis Roosa).

The tasks associated with every milestone are done in the order in which they are presented here. For example, we write the acceptance tests against the empty stubs before we write the actual code. Another thing that should be obvious is that we spend a lot of effort on planning and design. We are extremely rigorous in our design review, we look at the API from various different angles (we consider different options, we discuss naming, usage, simplicity, statelessness, future evolveability, etc.) employing both scenario-based design and producing various short-lived and long-lived documents. We have found that this saves us a lot of time during development and significantly increases the confidence of our dates.

Simple, Predictable, Agile

The simplicity and predictability of this process have a lot of positive effects – from team morale and cohesion to delivery on time with high quality. To date, we have always been done with M4 on time or ahead of time! The process does, however, have a waterfallish feel, so every once in a while I get questions about agility. Put simply, we believe that design and planning is important, but so is time to market and getting frequent customer feedback.  We resolve that tension by having short release cycles (3 months or less). There is noting that is preventing us from making these cycles even shorter, but we have found that 3 months works well for us.

My experiences shows that you can’t achieve agility by cutting proven engineering practices such as solid design and code reviews – that only leads to fire-drills, death marches and low quality. You achieve agility by having a reasonably rapid development cycle, aligned to solid business considerations.

To Be Continued…

In my next post, I will introduce a process that is suitable for larger, more complex products and organizations.

• Q1. What do you do, and like doing?
• Q2. What do you do, and don’t like doing?
• Q3. What do you not do, but would like to start doing?

I ask folks to give these questions some thought and ideally send me a bulletized list of items before we meet in person to discuss them. I explain that I will try my best to minimize the items that fall under Q2, and maximize opportunities for items that fall under Q3.

Even though this technique is extremely simple, I have found it to be a great tool to anchor and guide career conversations. It provides just enough structure to facilitate the conversation, for a very low overhead cost.

Clearly, this technique also gives me the ability to intelligently balance responsibilities within the organization. Very often the old adage that “one man’s garbage is another man’s treasure” proves to be true, which of course makes everybody in the org happier. And happy people are productive people.

• Principles 1: The Essence of Driving – A Crash Course in Project Management
• Principles 2: Principles of Software Testing
• Principles 3: Principles of Software Development
• Principles 4: End-to-End Development Process
• Principles 5: End-to-End Development Process (for Large Projects)

+++

The third and fourth posts from my series on “Principles” outline a system of shipping of software, that takes into account the various lessons I have learned during my years as a manager at Microsoft, dating back to the first product I worked on – Windows XP. The post lists a set of guiding engineering principles that result in stable, high quality releases, delivered on time.

Before we jump into the principles, I want to call out a few things:

1. No exceptions to the rules: There is no such thing as partial implementation of these principles. Even though I take a lot of time socializing these principles in the organizations I manage and worked in, I and my managers tend to take a fairly assertive approach when implementing these principles and we apply them fully, 100% of the time. Yes, it takes a while to socialize these and yes, we get a few “you are not being agile” (see more on “agile” at the end of this post), “you don’t understand our reality, we are a special organization” and “can we make an exception for XYZ” comments. We still treat these principles as a Constitution and we (management) support them 100% of the time.
   
2. Real products get shipped with these principles: Everybody wants to ship a high-quality product, with compelling customer value, on schedule or ahead of schedule. As involved as these principles may sound, they are a very simple scaffolding that gets you to ship predictably with high quality.
   
3. Top management sponsorship, commitment and calibration is key: You cannot really achieve any significant change in an organization unless you have first-class sponsorship and commitment by the top of the organization. The top management team needs to be committed as well as well-calibrated i.e. different members of the top management team should come up with consistent answers when approached with the same problem.
   
4. Commitment eventually leads to organic adoption:  Solid principles and processes inevitably lead to cultural changes in the organization. As managers, that’s exactly what we want to achieve – a cultural shift in the organization that results in organic rejection of bad practices, and an appetite for continuous improvement. 

+++

Everybody on the team fully understands the plan.

For a team to be successful, everybody on the team needs to (at all times) understand “the plan” for the release and his/her role in its various cycles and milestones. The litmus test here is asking a random person on the team what “the plan” (schedule, owners, feature set) is.

Deliver features in a gradual, close-looped manner.

A common theme during software releases is a fire-drill towards the end of the release, due to the syndrome of “biting more than we can chew” and due to managing the deliverables in an open-ended, “agile” fashion. One way to overcome this situation is ensuring that we deliver features in smaller “sets”, on a more frequent cadence. Every “feature set” represents a meaningful collection, which gets developed and stabilized together before proceeding to the next set.

Thus, we end up with a number of “feature set development cycles”, producing stable sets that integrated together comprise our release. I like to use the metaphor of “putting features in the freezer” i.e. we start working on the new feature set only when we have gotten the current feature set to high shippable quality.

Define release criteria at the start of the release cycle. Track regularly.

This sounds like a common sense “must do”, but it is regularly not done sufficiently well. The release criteria generally fall into two groups: (a) RI release criteria, necessary to RI (reverse integrate) a feature into the main product branch and (b) shipping release criteria, necessary to release a feature or a set of features. We need to have the complete list of both before we check in a single line of code. That helps us understand the true cost of every feature.

Defect prevention – whenever possible.

A lot of our effort is spent on generating and fixing defects that could have been prevented in the first place. We need to make heavy use of all available tools in an attempt to prevent as many defects as possible from entering the product in the first place.

Examples of such defect prevention opportunities are enabling of tools such as FXCOP in the build environment, by default.

Have a stable, fully-transparent, committed schedule from the start.

Another common challenge in software releases is the lack of a stable, transparent, predictable schedule. Our product schedule mimics our features. It starts as a very “low-quality” feature, progressively solidifying throughout the release, as a result of “we are not on track” realizations.

I have heard claims that the schedule of the parent organization (division, company, etc.) is too “fluxy” which in turn affects the ability of the team to build a predictable, stable and transparent schedule. Even if we assume that this claim is true (it probably is, but it should not be – large companies and divisions prove that they can ship with a stable schedule), the local team still has the ability to be in control of its own fate by defining stable sub-schedules to combat randomization from the larger organization.

Having a stable, transparent, fully-internalized and fully-embraced schedule is a key ingredient to the success of any product – big and small.

No code while planning the “What”. No code without spec.

PM spends the first milestone in the product cycle (MQ – the quality milestone) on defining the “what” for the release. Dev and Test complete engineering debt work, preparing the engineering system for execution. While there may be limited prototype code generated during this milestone, none of this code is allowed to be reverse-integrated in any official branch. Dev and Test should spend the majority of their time stabilizing the engineering system (builds, static analysis tools, unit tests, functional tests and infra, stress tests and infra, performance tests and infra, meaningful reverse-integration tests to prevent other teams from breaking us, etc.) Having a stable factory will ensure producing a stable product.

Dev and Test start working together on the features in M0 (not earlier) once the “what” has been defined, scratching any previously generated code.

Fully working and timed setup on day 1 of M0.

Another common problem teams face is Setup instability that typically carries on, way into the release. Not having a stable Setup complicates significantly lab operations and prevents the team to self-host the build and discover issues early, so it is something that needs to be addressed.

Setup must always be stable and must visibly display the important metrics that we are optimizing against. Metrics such as speed (of setup), number of custom setup actions, etc. should be visible to the whole team from the start.

Strict and reliable reverse- and forward-integration gates from day 1 of M0.

If we believe that reverse- and forward-integration (RI and FI) gates have a valuable role in ensuring the health of the team branch, then we must ensure that the gates that we have in place are reasonable and that they are strictly adhered to. This simplifies immensely feature development, by defining a simple “rule” for RI-ing and FI-ing code that can be easily understood and embraced by the team.

No code changes in the team branch will be allowed without a fully operational test and validation systems (unit tests passing, test infra running, functional tests at 99.5% pass rate, Perf lab running, Stress lab running, Code Coverage generating results).

Start together, work together, finish together.

A company or a division ships a successful product by getting all team to adhere to the same fundamental schedule and gates. A development organization can and should be doing the same. Having a single schedule with a single set of expectations for all teams simplifies management of the release and creates synergy between the feature owners.

Some claim that “agility” is achieved by having different feature teams work against different schedules. My experience is that such pseudo-agility results in a fragmented organization, that is confused about its own deliverables and that delivers low-quality products, because products are not built with the same rhythm. Management of the product deliverables in such situations often degrades to “managing exceptions” as opposed to “managing by the rules”.

We can and will achieve agility through the power of contained, incremental milestones, not through randomization.

All teams in the development organization should start together, work together and finish together, adhering to a common schedule, RI gates and exit criteria. All disciplines (Dev, Test, PM) should do that too, working side by side as opposed to serializing work.

No work happens outside of the main development cycle.

“Out-of-band” releases and “off-the-books” investments are good and necessary, but they must be planned as all other work and managed within the constraints of the main development cycle.

This means that they never appear randomly in the middle of a development cycle (they can appear on the backlog to be considered for the next dev cycle). This includes dev work, test work, prototypes, forum engagement, conference prep work, etc.

Every major system has an owner.

Every major system on the team (“system” being a generic name for anything that needs an owner) has clearly defined and documented ownership. This includes, but is not limited to fundamentals, lab systems, build systems, test systems, infrastructures, etc.

+++

A final word on AGILITY.

AGILE is a magic word in our industry these days that gets thrown around somewhat lightly in my opinion. Some people hide behind the term AGILITY to justify the lack of basic structure, basic process, and basic planning adequacy in their organization. Invariably such pseudo-agility leads to constant fire-drills, regular death marches, and the eventual burn out of the team.

It is my strong belief that every project and team needs basic “scaffolding”. Larger projects and teams tend to need a bit more of that, at least until the scaffolding gets transformed into “team culture”. 

Clearly, the team leaders have to be accountable for providing that basic scaffolding. Success is easy to define – if you have a happy, productive organization that delivers high-quality products on time, then you have provided the necessary basic structure.

I am of course aware of the goals of the agile movement, which I am very much supportive of. The best way to achieve agility in my opinion, is by sizing of your development cycle appropriately – a technique that I will demonstrate in my next post.

• Overview of TestApi
• Part 1: Input Injection APIs
• Part 2: Command-Line Parsing APIs
• Part 3: Visual Verification APIs
• Part 4: Combinatorial Variation Generation APIs
• Part 5: Managed Code Fault Injection APIs
• Part 6: Text String Generation APIs
• Part 7: Memory Leak Detection APIs
• Part 8: Object Comparison APIs

+++

Comparing two objects for equivalence is a relatively common task during test validation. For example, you might test whether a type follows the rules that are required by a particular serializer by saving and loading the object and comparing the two. In a deep object comparison, all the properties and their sub-properties are compared repeatedly until primitives are reached. The .NET Framework provides mechanisms to perform deep comparisons, but requires the types to implement part of the comparison logic (IComparable, .Equals). Obviously some types do not use these mechanisms. This API provides a mechanism to perform a deep comparison of two objects by using reflection, regardless of whether or not they implement IComparable.

TestApi Object Comparison

TestApi provides an API to create compare operations. The API separates the comparison operation into two parts:

• ObjectGraphFactory: Builds an intermediate representation from the object that describes what needs to be compared.
• ObjectComparer: Uses a reusable compare mechanism to compare the intermediate representations of the objects, generated by the factory.

Example #1

This example demonstrates how to use the object comparer to compare two objects. Assuming we have the following simple class...

class Person
{
    public Person(string name) 
    { 
        Name = name;
        Children = new Collection<Person>();
    }
    public string Name { get; set; }
    public Collection<Person> Children { get; private set;  }
}

… we can compare two objects using the following code:

Person p1 = new Person("John");
p1.Children.Add(new Person("Peter"));
p1.Children.Add(new Person("Mary"));
Person p2 = new Person("John");
p2.Children.Add(new Person("Peter"));
// Perform the compare operation
ObjectGraphFactory factory = new PublicPropertyObjectGraphFactory();
ObjectComparer comparer = new ObjectComparer(factory);
Console.WriteLine(
    "Objects p1 and p2 {0}", 
    comparer.Compare(p1, p2) ? "match!" : "do NOT match!");

Execution of this code produces the following output:

Objects p1 and p2 do NOT match!

Example #2

The following example demonstrates how to obtain the details of where the two objects do not match.

Person p1 = new Person("John");
p1.Children.Add(new Person("Peter"));
p1.Children.Add(new Person("Mary"));
Person p2 = new Person("John");
p2.Children.Add(new Person("Peter"));
// Perform the compare operation
ObjectGraphFactory factory = new PublicPropertyObjectGraphFactory();
ObjectComparer comparer = new ObjectComparer(factory);
IEnumerable<ObjectComparisonMismatch> m12 = new List<ObjectComparisonMismatch>();
Console.WriteLine(
    "Objects p1 and p2 {0}", 
    comparer.Compare(p1, p2, out m12) ? "match!" : "do NOT match!");
foreach (ObjectComparisonMismatch m in m12)
{
    Console.WriteLine(
        "Nodes '{0}' and '{1}' do not match. Mismatch message: '{2}'",
        m.LeftObjectNode != null ? m.LeftObjectNode.Name : "null",
        m.RightObjectNode != null ? m.LeftObjectNode.Name : "null",
        m.MismatchType); 
}

Execution of this code produces the following output:

Objects p1 and p2 do NOT match!
Nodes 'Children' and 'Children' do not match. Mismatch message: 'RightNodeHasFewerChildren'
Nodes 'IEnumerable1' and 'null' do not match. Mismatch message: 'MissingRightNode'
Nodes 'Children' and 'null' do not match. Mismatch message: 'MissingRightNode'
Nodes 'Count' and 'null' do not match. Mismatch message: 'MissingRightNode'
Nodes 'Name' and 'null' do not match. Mismatch message: 'MissingRightNode'
Nodes 'Count' and 'Count' do not match. Mismatch message: 'ObjectValuesDoNotMatch'

Example #3

The following example demonstrates how to create a custom object graph factory which determines which nodes in the object graph to compare.

For simplicity, we construct a factory that disregards any children.

class SimpleObjectGraphFactory : ObjectGraphFactory
{
    public override GraphNode CreateObjectGraph(object o)
    {
        // Build the object graph with nodes that need to be compared.
        // in this particular case, we only pick up the object itself
        GraphNode node = new GraphNode();
        node.Name = "PersonObject";
        node.ObjectValue = (o as Person).Name;
        return node;
    }
}

Then, we utilize the factory to generate graph representations of the two object we want to compare.

Person p1 = new Person("John");
p1.Children.Add(new Person("Peter"));
p1.Children.Add(new Person("Mary"));
Person p2 = new Person("John");
p2.Children.Add(new Person("Peter"));
ObjectGraphFactory factory = new SimpleObjectGraphFactory();
ObjectComparer comparer = new ObjectComparer(factory);
Console.WriteLine(
    "Objects p1 and p2 {0}",
    comparer.Compare(p1, p2) ? "match!" : "do NOT match!");

Execution of this code produces the following output…

Objects p1 and p2 match!

… which is the expected result, given the fact that our simple factory completely disregards the Children of Person.

Conclusion

Comparing of objects is a common problem in automated test development and TestApi provides a simple generalized and extensible solution.