Feature Parity vs. Scenario Parity

It can be easy to miss the forest through the trees.

Sometimes there are emergent properties from the individual feature items, which in turn provide some new "implicit" feature to the end-user. Such features can lead to very useful end-user scenarios, but aren't usually captured by a specific feature list. 

I find this comes up in conversations when some team wants to propose a major breaking change, and then asks other teams "what's necessary to achieve feature parity in light of this breaking change?" Just going down the list of existing features does not do this justice. Key end-user scenarios may fall through the cracks.

 

Some common ways to get feedback on this sort of thing:

• Internal Dogfooding,
• scenario documents,
• good coordination between teams
• understanding the problem space
• Beta-testing

 

Here are some examples from debugger issues:

1) Parsing: The '!' character is a module separator for native symbols parsing libraries. Managed methods names generally don't use a '!' symbol, although the spec technically allows them to use that.   So the native symbol parsing libraries can actually be applied to managed methods with some success. If managed methods uses the '!', it would break the tools that use the native parsing libraries on managed code.

2) Methods used to be jitted into a single contiguous blob. This meant that you could view the entire method in a standard disassembly window at once.  Once methods can be jitted to multiple blobs on different pages (which can be a sweet working set optimization), now you can no longer view the entire method in the single disassembly window.  The debugging APIs can be extended to describe all the blobs (getting back to "feature parity"), but to get real end-user scenario parity here, you'd need an advanced disassembly window that can get the blobs and stitch them back together.

3) (This example is completely hypothetical). ICorDebug does not support Edit-and-Continue (EnC) for in-memory modules (eg, modules loaded via Load(byte[]). Let's say a debugger launches the debuggee under a host application which I'll call MyHost.exe.  Say MyHost.exe loads the user's modules from the file system. EnC works and everybody is happy. If MyHost.exe for some reason started loading the user modules as in-memory modules, suddenly the end-user EnC experience would be broken.  ICorDebug kept full feature parity, but the end-user experience would be busted.

Comments

• Anonymous
  September 06, 2007
  This is an interesting point.  You've focused in your examples on APIs quite a bit, but it's just as true for more user-visible features. Something I'll be doing over the next couple of months is rewriting a fairly significant feature in our app, due to some design and implementation flaws, and this sort of thing is what I've been worrying about.  I'm trying very hard to make sure it still lets users do everything they could with the old one.  So this is a timely post for me, thanks for writing it!

• Anonymous
  September 10, 2007
  David - glad you found it useful! I find it's impossible to have a comprehensive list of how people are actually using something. That's where Betas + dogfooding can be very useful.