MACROMEDIA CASE STUDY (Cont.)

"Why a simple fix is not always so simple" Example

Macromedia was working on an update to its Flash product codenamed Ellipsis and had asked for feedback from their customers. One customer asked if a fix could be implemented in the next release. When searching for script in the application's scripting editor a panel window is opened, the 'find panel'. However if the panel window remains open it is not possible to change or edit any text in the scripting editor. The Macromedia team initially thought this problem would be very easy to fix.

In the development process of Ellipsis the team determined they would focus on those issues that affected a lot of users and do not risk or touch a lot of the code in the software. Reviewing the 'find panel' issue, the Macromedia team had thought that the issue would be easy to fix, however they discovered that it was not easy to fix. The team had a criterion for whether they would fix the find panel problem.

1. How easy (code wise) it would be to fix the problem.
2. How risky the fix would be (would it affect code that affects other parts of the app).
3. Would the fix cause any new usability issues.

As it transpired the fix would have affected every aspect of the three criteria and there would have been a significant changes required of the application. Quoting from an email posted by Chambers on his blog http://www.markme.com/ flashteam/archives/2004_09.cfm:

"The head of engineering asked an engineer to look into the issue. It looked like it would be an easy fix, and an easy win for users (which is a win for us). So, the first item that came up was actually usability related. There were concerns that it would be confusing to users if the Find Panel was open but the ActionScript editor had been closed. What should the panel do if the user clicks find then? What if they keep the panel open, but open a new frame of ActionScript? We looked at how other programs handled this (Visual Studio, EditPlus and Notepad), and determined that this would not affect many users, and that the other programs have similar issues.

So, the engineer then looked into how easy and risky it would be from a code standpoint to make the change. It turned out, that in order to make it non-modal, we couldn't just flip a Flag, but rather had to call a new method. Ok, a little more risky, but not that big of a deal.

After further investigation, we discovered that we would actually have to change the window type, which in essence would mean we would have to reprogram the Window. Again, not yet that risky, but now we are getting into more significant changes.

Finally, and the straw that broke the camels back, we found out that we would have to completely rewrite how the Find panel actually finds data. This is because currently, when you open the Find Panel, it takes a snapshot of the text in ActionScript editor (since the user won' t be able to change it). I am not sure why it is done like this, but do know that it is faster than dynamically loading the text each time and keeping the cursor position each time.

Changing how the Find Panel searches text is big code change and risky. Furthermore, making the change could now lead to significant performance decreases when searching large amounts of text.

These factors combined to make the change too risky for Ellipsis, and we deferred it to the next version of Flash (at which time we are basically re-writing all panel and window code).

Anyways, I just wanted to share this with the list to give some context to why something that may seem simple, doesn't get fixed for Ellipsis. This was an issue that I thought would be very simple for us to fix, but it turned out to be a lot more complicated and risky than I expected."

Here is an example of how Macromedia used weblogs to answer a customer's specific request for a change in the application, but because of the work that would be required to fix the issue, the whole project would of taken longer to complete and costs would have risen for customers. With this post, Macromedia demonstrated they involve customers in the process of fixing problems.

Customers commented on the blog post stating that they appreciated understanding the Macromedia development process and understood why Macromedia was making the decision they were for the development of the product. If customers are involved in the process of software product development it changes customer's perception of the process, rather than them and us, involvement in the process empowers customers, they start thinking that they are part of the Macromedia team. Chambers said, "The customers feel more vested in the whole development process, they have more ownership."