In over 20 years of professional software development, I’ve never yet worked on a software project that had sufficient time and resources to do everything we wanted. One of the most painful tasks that project leads face is making tough choices about what features to add and remove, and what bugs to fix. Alas, Expression Web is no exception.
When you’re dealing with an application with so many features, it’s not really a surprise that there might be a few bugs. The real question is, given our limited resources and time, how do we decide which bugs to fix as we individually review each bug? Before I answer that, let me back up a step and review the various ways that bugs are found and submitted for triage.
All of these bugs are added to our bug database and they are considered, and occasionally reconsidered, in daily triage sessions. These triage sessions include one or more representatives from the development team, the test team, and the program management team. Discussions in our triage meetings can be fairly extensive, and occasionally heated, as we tend to be very passionate about the quality of our program, as well as the importance of meeting our deadlines.
So how do we actually decide which of these bugs to fix? We look at several factors:
An example of a really painful triage decision we had to make in Expression Web 2 was the issue of link fixup for PHP include files. A bug came in fairly late in our development process regarding including a PHP file in an HTML file, then renaming that PHP file. In other link fixup scenarios, the program recognizes that you have renamed a file that is referenced by other web pages and asks you if you want to automatically adjust the links to point to the renamed file. For included PHP files, this process was failing.
After careful investigation, we had the following answers for the various triage criteria:
Earlier in the development cycle, this bug is a no-brainer to fix. It’s a core scenario that is likely to affect many of our users, in an area where we’re investing significant resources. End users can work around this issue by using the Find and Replace feature, or manually updating their links, but that’s not as convenient and it’s contrary to our behavior with other types of included files. However, given the risk, the cost, and the time that the bug was reviewed, we ultimately decided that, painful though it was, we just could not take this fix for Expression Web 2. I’m pleased to say that the bug has already been reconsidered for, and fixed in, Expression Web 3, and that the fix will be available in our first preview release.
As you can imagine, seeing the list of criteria, not to mention seeing how subjective many of them are, our triage sessions are often contentious. At Microsoft, one of the core attributes we value and cultivate is passion and we definitely have a lot of passion around which bugs we want to fix and which we don’t. At the end of the day, though, the one thing that holds us together is that we also have a passion for doing the right thing for our end users. Sometimes, the right thing is to not fix the bug, as with the example I cited above. We just could not take the risk of destabilizing the program, potentially causing any number of other problems for our end users, painful though that decision was. Sometimes, though, and these are happier decisions, the right thing is to fix the bug, as was the case when we re-triaged the bug for Expression Web 3.
If you are ever wondering whether you should submit a bug report to the Expression Web team, the answer is an unqualified yes. We need this kind of feedback from you, our end users, in order to help us meet our goals for shipping a quality product. The detail you provide in your bug report could be the final clue that helps us track down the cause of the bug and yours could be the report that helps us fix a bug that thousands of our users could encounter. We need the feedback from you, both positive and negative, in order to help us assess whether we’re meeting your needs and our own goals. Without you, and your support, we cannot succeed. We are always grateful for any feedback you can provide and will always do whatever we can to meet your needs.
Paul Bartholomew Development Lead Expression Web
The secret life of software bugs, exposed! is a very interesting look into the software bug process within
As you can imagine, seeing the list of criteria, not to mention seeing how subjective many of them are, our triage sessions are often contentious. At Microsoft, one of the core attributes we value and cultivate is passion and we definitely have a lot of passion around which bugs we want to fix and which we don’t. At the end of the day, though, the one thing that holds us together is that we also have a passion for doing the right thing for our end users.