If you look carefully at the code for the Copy to Device addin (which needs a good name) you will also notice I used Pascal Casing and Daniel used camel Casing.
I thought about refactoring the code to be consistent with .net framework guidelines before releasing it. I decided against it since I wanted to get this addin finished and submitted to some volunteers to test it. Granted, the amount of time to make the changes in an application this small is trivial, but it's also not zero. Since the addin was working I did not want to take a chance on breaking anything, and left it as it was.
Plus, if there's a bug lurking in there, it will be easy to track whose method is at fault.
One piece of feedback I got was there is no indication of success after the page was copied. I didn't want a dialog popping open each time the page was copied but now I'm thinking of putting in a small message box to show success. Of course, I'd let you turn it off forever as well.
This is a great example of a feature request coming in. The product may be working exactly according to specification, but the specification may not be what the user wants. These late changes also can result in big problems later. While this is a simple example, it could still have the potential to hold up shipping this addin.
Consider, as a tester, I have to make sure this addin works across every supported configuration, such as Windows versions, phones (for this addin), color depths, etc… Since this is English only (change the reg key to alter the text on the button if you want), I don't have to worry about localization problems for different languages.
You can imagine a bug, though, in which the small, unobtrusive dialog I wanted to signify success could be too small to hold a localized word for "Success." If that happened, it's back to changing resource files and testing new builds, and that takes time. From that point of view, I do not want to pay the time costs to add and test a new feature. I need to move on to other things, like testing OneNote.