Saturday, May 07, 2005

Performance..What?

I have said it before and saying it again. Microsoft needs to ship a quality product that exceeds customer expection for reliability, performance and functionality. There is no point in shipping products every other year with incremental changes just for revenues sake. I see many examples of this quite often and especially in the product I work in. Here is a real story:

A Program Manager who works in some other product division came to my Office asking for my help fixing the solution she deployed. She built a solution using the product I work on because it made their process better. She spent days creating the solution and after deploying it, nobody in her team wants to use it because the performance is so bad. Editing the document is very slow and the users are staying away because of that. The way she put it and shared her story, I really got emotional and felt bad for not being more proactive and vocal about product performance. I looked at her solution and saw that it wasn't a very complex solution but not simple either. Spent some time with my colleagues trying to find some tips on improving the performance and in end couldn't do much (It would have required re-writing the solution).

I did something about it and talked to the performance guys. The problem turned out to be the mindset. The common answer to performance problems that the performance team would get was:

  • Why would someone display 1000 rows of data instead of filtering it?
  • This is stupid scenario
  • Why would anyone want to do that?
  • This is not our issue. The external component X is the bottleneck

So the performance team ended up writing some guidelines for easing the performance problem. But we were all dead wrong. Most the real world solutions that I saw are above the mark we set and they perform badly. In other words, customers are doing things we thought were bad ways to do things and said all the time that there was a better way to do these things.

Customers aren't stupid to build solutions that doesn't scale or do stupid things. Just as we all do, we learn from our mistakes. I write much better code than I did a few years ago. I didn't want to write bad code few years ago but I did because I didn't have the knowledge that I have now. But the lack of knowledge didn't stop me from achieving my goals or do things that I wanted to do. A desktop application that is used by everyone has to perform reasonably well in such situations. Note that we are not taking about C++ compiler performance for badly written code. We are talking about applications like Microsft Word (e.g.) that slows down trmendeously when used differently.

What is the remedy?

It is the mindset stupid!

  • Don't assume that everyone who is using your product is Raymond Chen or Charles Simonyi.
  • Expect some unreanable uses and don't expect that everyone has time to read books and manuals before starting/getting their job done
  • Take resposibility for the performance of the external component that you use. If that doesn't scale well, invest time in it to re-write as customer benefit far exceeds our financial goals
  • Make performance part of the process and not an after thought
  • There is more but I need to go :-)

Note: I stopped using Outlook and instead switched to OWA. Now my days go a lot smoother and I do a lot less cursing everyday. Outlook Guys, your product has a lot of nice features but if it will only perform well in an ideal environment, you guys totally got it wrong. I can't understand how a version 11 of a product can have still such issues as performance and reliability!!

No comments: