by Michael S. Kaplan, published on 2005/08/22 19:30 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/08/22/454839.aspx
Maybe our good friend Bill Shakespeare should have hired Kate Gregory's Gregory Consulting to do some of the writing for his play Macbeth. Because then the line in the title could have been distilled down into the much shorter term Fail Fast.
Now I know that is not exactly what Shakespeare was saying, but as Kate describes this is not a development philosophy that pines for failure. It is always better when you design software systems in such a way that they will succeed when they can, but if they cannot the failure will happen much more quickly. As she mentions:
This leads to all kinds of useful practises like doing the risky bits first, prototyping, making little proof of concept apps or subapps, and the like.
Perhaps this is the most important point; software that is designed in such a way that you put all the pieces together and really do not know until the very end whether they are going to work properly is pretty risky software. People don't really think about this issue enough, and I think she does an excellent job at reminding us.
When you add internationalization issues to that mix, if you do not know whether particular languages are going to work properly in an application then it is a really bad idea to find out about this when you're about to ship. You really want to make sure that other languages work as early as you can. Now perhaps the support for language is coming later also, but you certainly want a plan out schedules in such a way that you are testing these features early and often.
I was thinking about this very issue the other day. I was showing off a sample application that Cathy Wissink and I had used for screenshot for an article that we wrote (coming up in the October MSDN Magazine!). In this sample, we were showing text in a Whidbey application that use all of the new languages and scripts supported in Vista Beta 1, and the fact that all of these languages worked properly even though they would not work properly in .NET 1.1 since GDI+ had no information about how the script was supposed to work. Of course, this was showing off some of the else's features. But they were pretty cool features of WinForms and Uniscribe, not to mention some of the new culture support in Whidbey.
We noticed that out of all of the new languages, a single language in a single control was showing null glyphs (square boxes) rather than the expected characters. People immediately worked to get a bug report entered, since this language was definitely supposed to work -- with fonts present and font linking on. There are always going to be small bugs like this present, which is why it's great that we have testers. But the most important issue is that just about everything else was working properly, because the design of all the underlying features was done using processes that create easily testable features that did not require us to wait until the end to see if every language worked properly. Since this involves integrating features across NLS, typography, .NET globalization, and WinForms, knowing that a lot of people have been doing that testing first on all these different entities kept me from being afraid that the application was just going to fail....
In any case, congratulations to Kate and to Gregory Consulting, for 20 years of doing it right and getting it done.
referenced by