I heard the other day that the difference between ranting and constructive criticsm
is the offering of a solution so let me rant first and then I will offer a possible
solution. So first the problem. I sent out an e-mail with a Microsoft Project 2007
.mpp file attached. I heard back from one of the people that I sent it to that they
could not open the file. I wasn't sure if it they had an older copy of Project or
didn't have Project installed on their computer. I decided to go into Project and
do a "save as" on the file to an older version and print a XPS file that I could also
e-mail. While saving to the older version I saw that I could save to Excel and decided
that might be a better option. I ran through the wizard asking me what columns I wanted
saved to the Excel workbook. I foolishly clicked on the button to add all and then
had to go through and delete most of them since they were not populated in the Project
file. After cleaning up my mess I finally got through the whole wizard and clicked
on finish only to get a message that the Excel workbook couldn't be created because
of security settings with a somewhat terse message on how to fix the problem. I was
able to do the 2 steps to get to the dialog box where the instructions started and
reset the security settings. The second time through the wizard I was much faster
and I was eventually able to save the file. My complaint was with the error. I shouldn't
have ever had to see it. I can see 3 possible solutions to this problem.
1. The option to save to an Excel file could have been disabled. I would have seen
that there is a possibility and could have looked in the help file to figure out what
I needed to do. I am not sure how effective this would be because I would have likely
determined I didn't have the correct driver or something and instead printed to the
XPS but at least I would have known that when the sun, moon, and stars all align just
right I might be able to save as Excel.
2. I could have been told that my security settings wouldn't let the wizard finish
and asking me if I wanted the security settings to change. I don't really like the
idea of a "black box" security change and would be tempted to say no most of the time
but given the amount of time that I had invested in this (100% my fault) I might have
been tempted to accept the option and try to undo it later.
3. The second screen of the wizard (you know the one after the splash screen that
nobody bothers to read) could have checked the security settings and told me that
I couldn't finish without making some changes. It could link to a help file with accurate
instructions and a full discussion of the tradeoffs I was making by changing the security
setting.
Option 3 seems so simple and certainly like it should be the logical choice so why
wasn't it taken? I have no idea. I *suspect* that the reason might
be that this particular feature wasn't tested or that it was automatically tested.
I can see automatic testing being the most likely culprit. If I were given a specification
for a feature that says if a certain security feature is set a message should appear
and the file shouldn't be created I am pretty sure I could write an automated test
to determine that is what is happening. Since I might only have to watch it run once
if even that many times to make sure the test ran correctly and then I wouldn't have
to think about it any more. I could also see reusing another test to fill out the
dialog box so it wouldn't be like you were taking a lot of time to set up everything.
My solution to the problem would be to have the automated tests run at least once
manually during each product development cycle to make sure that they still make sense
and that they test the correct functionality. I am not sure what the cost of all this
manual testing would be verses the amount of complaints Microsoft gets from customers
but there should be some way for Microsoft to check the number of calls coming into
PSS and just check the tests that are designed around those features.
Read the complete post at http://www.grokdev.com/Blogs/scott/2008/04/13/IfYouKnowThatWhyDidntYouTellMeSooner.aspx