When I was in a cooking class at Le Cordon Bleu in Paris, the master chef completely showed off his amazing skills, tricks and secrets by demonstrating sample dishes. Students were encouraged to ask any questions, but classroom policies included - no recording, and no printed recipe handouts.
Of course, students take notes. Those who write fast probably have handwritten Cordon Bleu recipes, on the printed ingredient lists.
I understand it was a tradition at Le Cordon Bleu, but I doubt if it was necessary.
Not because students can always take quick notes, not because they can sneak in micro voice recorders in their pockets. Simply because, having the detailed recipe doesn't automatically make you a good chef.
Cooking is more than a skill. Cooking is an art. As with every other form of art, mastering the skills is far from enough. You will need to put in your heart to be an artist.
Don't get me wrong. I am not saying cooking cannot be learned. Indeed it can be. Practice on techniques is the first step, but to be successful, you need to stand out. What differentiates a line cook and a chef is the emotion and soul that scream to jump out of the dishes on every bite. This is the secret sauce of becoming a good chef.
Similarly, open source software doesn't hurt the software company either.
Of course, the ideas in each software product are protected by patents. But put intellectual property rights aside, there are secret sauces why successful software companies are successful.
There will always be people who pirate-copy softwares, but they won't enjoy the proper support if they run into problems. They might not even get software upgrades as in Microsoft case.
There will also be people who prefer downloading the source code of an open source project and spend time compile it by themselves. But that's not for the majority of us. We want a friendly and guided installation experience. We want the driver for a particular device to be automatically identified and installed, rather than research by ourselves.
There are more and more software vendors who give out licenses at ridiculously low price, but charge for professional services and support. Customers are willing to pay for service because instead of having to figure out how to make the best of the software, why not asking the expert to provide help? They know the best practices of using it, they provide timely solutions, they make guarantees.
Think about Neiman Marcus and Macy's. There is an overlap of the brands and lines they carry. Why would someone shop the exact same items with a marked up premium at Neiman (not to mention they have to use American Express)? Neiman has unparalleled excellent service. The brand sales are knowledgeable about their products, what's hot and what's coming. They are friendly. In addition to selling things to you, they are also interested in making you proud of making an investment in buying their brands. Shopping there is an experience.
Tuesday, May 24, 2011
Sunday, May 22, 2011
Maker Faire
Maker Faire promotes DIY. I still remember the old days that my dad used to make walkie talkie himself, with see-through plastic case that the circuit board and components inside were totally visible; he also made (assembled) a TV himself, with a nasty card board as front around the CRT, and with the back of the TV totally exposed. They weren't pretty, but they were innovative. At that age, not many people in the place I grew up had ever seen a TV.
The very reason I didn't become an electrical engineer even though I attended EECS at school was because I was never a handy man. Consider building a walkie talkie. In the old days, you didn't have a kit that every component was prepared for you and all you needed to do was to assemble; instead, you would need to print and cut the circuit board yourself! This would be too much for me.
I had chosen software programming. It was much much much easier. You could still use your creativity, but the assets you will need, the complexity of the project is much much much less. Yes, you need a Java compiler and a runtime. In the old days where no existing library, you would need to write your own. But, these are not on the same scale as printing your own circuit board!
Cooking is in between. It's definitely not as complex as hardware DIY, because the assets you need are quite simple - cookwares, ingredients. It's not as straightforward as software, because it not only needs an innovative mind, but physical skills as well. But without a doubt, cooking is a creative process, similar to DIY and software.
Solute to DIYers!
Solute to DIYers!
Monday, May 16, 2011
Labor Illusion
We have been to a restaurant lately where we waited for our food for longer than we could ignore.
HBR study shows that customers do not particularly hate waiting for your applications to process, as long as you show them what you working on, or, at least, what you pretend to be working on.
This is called labor illusion. It's a demonstration of effort, whether literal or not, expended to meet the customer's request.
Apple voice recognition software will mimic the sound of typing while processing, ATM shows the images of counting bills while customers are waiting for their cash.
Funnily, experiments show that customers who endure waits but see a running tally of tasks end up happier than those who don't have to wait at all!
With this, I encourage all restaurants to have open kitchen, or bar setting that customers can see the cooks work. Even if you can't bring up dishes quick enough, labor illusion that cooks work hard (even if they may not be working on your order) helps more than giving customers another free loaf of bread.
In software products, don't be shy to take more time at processing. Just remember to show customers what you are doing behind the scene. Maybe show a magnifying glass over documents in an insurance claim application, or, an animation of sifting through expensive cars in processing a used car search query.
HBR study shows that customers do not particularly hate waiting for your applications to process, as long as you show them what you working on, or, at least, what you pretend to be working on.
This is called labor illusion. It's a demonstration of effort, whether literal or not, expended to meet the customer's request.
Apple voice recognition software will mimic the sound of typing while processing, ATM shows the images of counting bills while customers are waiting for their cash.
Funnily, experiments show that customers who endure waits but see a running tally of tasks end up happier than those who don't have to wait at all!
With this, I encourage all restaurants to have open kitchen, or bar setting that customers can see the cooks work. Even if you can't bring up dishes quick enough, labor illusion that cooks work hard (even if they may not be working on your order) helps more than giving customers another free loaf of bread.
In software products, don't be shy to take more time at processing. Just remember to show customers what you are doing behind the scene. Maybe show a magnifying glass over documents in an insurance claim application, or, an animation of sifting through expensive cars in processing a used car search query.
Sunday, May 15, 2011
The French Laundry and Unit Tests
In an article about the legendary Michelin 3-star restaurant - The French Laundry - in September last year, there was an interesting quote:
... in a further twist that differentiates them from most other line cooks, French Laundry cooks don't taste their completed dishes. Keller explained that if the cooks taste each component, and know that the flavor profiles work, the finished product will also work.
I didn't quite appreciate Thomas Keller's food on my visit last October (read my review here), but this kitchen strategy is smart.
Too many times, test cases in our softwares are end-to-end, which are, first of all, difficult to execute, and not efficient.
In a web-form registration application, we, for every release, test the complete application with combination and permutation of test cases. Every single executed test case exercises all the components of the application, from presentation UI, to form fields validation, to database insertion.
Consider these 2 test caes: 1) phone area code has to match city, and 2) password must at least 8-character long. There is really no need to exercise complete user flow to test them. Both test cases are around validation logic, and should be covered in validation unit tests.
The key is to divide your applications into "units". These units are logically isolated, can be owned and developed independently, and, best of all, can be tested individually.
For example, this registration application can be divided into presentation, validation, and database access layers. Each layer is tested, assuming the other layers work. Presentation testing focuses on the layout, spacing, spelling, usability, etc.; validation tests business logics; and database access layer tests the interaction with underlying data model.
To make it successful, a clearly defined boundary and interface is needed between layers (analogy: Chef Keller who designs the menu to put individual line cook's contribution together). This is the basis we can make assumptions that the other dependent components work as expected. Validation layer has to take it for granted that UI sends the user input correctly to it; database has to assume validation has already cleansed the data, so what's passed to it to be persisted is kosher. SOA has been used widely to make this boundary clean, but well-defined method signatures or other methodologies work equally well.
Now, does it mean no integration testing is needed? Absolutely not. But integration testing is only required on a very limited scale, in fact, to test the boundaries and interfaces between these layers. For the above 2 test cases, only one integration test case is necessary. In fact, if you have 1,000 validation test cases and 5,000 database access test cases, only a few integration test cases are needed. Do the math, total number of tests will be 1,000 + 5,000 + X, but in the old world, it will be 1,000 * 5,000.
Next time I go to Keller's restaurants, this learning will remind me to be more appreciative. :)
... in a further twist that differentiates them from most other line cooks, French Laundry cooks don't taste their completed dishes. Keller explained that if the cooks taste each component, and know that the flavor profiles work, the finished product will also work.
I didn't quite appreciate Thomas Keller's food on my visit last October (read my review here), but this kitchen strategy is smart.
Too many times, test cases in our softwares are end-to-end, which are, first of all, difficult to execute, and not efficient.
In a web-form registration application, we, for every release, test the complete application with combination and permutation of test cases. Every single executed test case exercises all the components of the application, from presentation UI, to form fields validation, to database insertion.
Consider these 2 test caes: 1) phone area code has to match city, and 2) password must at least 8-character long. There is really no need to exercise complete user flow to test them. Both test cases are around validation logic, and should be covered in validation unit tests.
The key is to divide your applications into "units". These units are logically isolated, can be owned and developed independently, and, best of all, can be tested individually.
For example, this registration application can be divided into presentation, validation, and database access layers. Each layer is tested, assuming the other layers work. Presentation testing focuses on the layout, spacing, spelling, usability, etc.; validation tests business logics; and database access layer tests the interaction with underlying data model.
To make it successful, a clearly defined boundary and interface is needed between layers (analogy: Chef Keller who designs the menu to put individual line cook's contribution together). This is the basis we can make assumptions that the other dependent components work as expected. Validation layer has to take it for granted that UI sends the user input correctly to it; database has to assume validation has already cleansed the data, so what's passed to it to be persisted is kosher. SOA has been used widely to make this boundary clean, but well-defined method signatures or other methodologies work equally well.
Now, does it mean no integration testing is needed? Absolutely not. But integration testing is only required on a very limited scale, in fact, to test the boundaries and interfaces between these layers. For the above 2 test cases, only one integration test case is necessary. In fact, if you have 1,000 validation test cases and 5,000 database access test cases, only a few integration test cases are needed. Do the math, total number of tests will be 1,000 + 5,000 + X, but in the old world, it will be 1,000 * 5,000.
Next time I go to Keller's restaurants, this learning will remind me to be more appreciative. :)
Saturday, May 14, 2011
Dual Dishwashers and Active/Inactive Database Tables
If you have a small kitchen like mine, you can't have 2 dishwashers. But I dream to have dual dishwashers. Why? The most obvious is capacity. After entertaining a crowd of friends, you will need the dirty dishes to be cleaned quickly. However, if it's just for more room, there are roomier washers that can fit more plates.
I would claim that the best benefit of having 2 dishwashers at a single home is the convenience.
How many times are you tired of unloading your completed wash, while your soiled plates are waiting in the kitchen sink?
With 2 dishwashers, you practically don't need to unload any more. Washer 1 contains clean plates where you directly take plates out of at dinner time, and washer 2 is where you stuff dishes into after dinner. When washer 2 is full, or, washer 1 is empty, simply kick off a wash cycle. Then, viola! Magically, washer 2 becomes your clean repository, and washer 1 is waiting for dirty ones.
Will it be confusing to home owners which one is the clean one? Yes, but, it's easy to solve, isn't it? Ever seen these kitchen magnets that have labels "Clean" or "Dirty" on them? As soon as you kick off a wash cycle, place "Clean" on it.
Now, as I promised, I'll show you how this concept is used in software engineering.
There are often needs to populate a database table with data coming from SAS reports, or business units, or external vendors. If you truncate the table and load the data, the production use cases will be interrupted (because once the table is emptied, applications read from the empty table).
The solve is quite simple - you need 2 dishwashers, urgh, I mean, 2 tables. Mark table 1 active and table 2 inactive. Production reads from table 1 (active). When the updated data file is ready, truncate the inactive table 2, load the data in. Then, switch active table to table 2, and mark table 1 as inactive. Now, production starts to read from table 2, and table 1 can be emptied any time. No downtime is required.
Hint: Clean/Dirty magnets don't help in the software example. Instead, you will need a global flag in database or application to indicate which table is active.
I would claim that the best benefit of having 2 dishwashers at a single home is the convenience.
How many times are you tired of unloading your completed wash, while your soiled plates are waiting in the kitchen sink?
With 2 dishwashers, you practically don't need to unload any more. Washer 1 contains clean plates where you directly take plates out of at dinner time, and washer 2 is where you stuff dishes into after dinner. When washer 2 is full, or, washer 1 is empty, simply kick off a wash cycle. Then, viola! Magically, washer 2 becomes your clean repository, and washer 1 is waiting for dirty ones.
Will it be confusing to home owners which one is the clean one? Yes, but, it's easy to solve, isn't it? Ever seen these kitchen magnets that have labels "Clean" or "Dirty" on them? As soon as you kick off a wash cycle, place "Clean" on it.
Now, as I promised, I'll show you how this concept is used in software engineering.
There are often needs to populate a database table with data coming from SAS reports, or business units, or external vendors. If you truncate the table and load the data, the production use cases will be interrupted (because once the table is emptied, applications read from the empty table).
The solve is quite simple - you need 2 dishwashers, urgh, I mean, 2 tables. Mark table 1 active and table 2 inactive. Production reads from table 1 (active). When the updated data file is ready, truncate the inactive table 2, load the data in. Then, switch active table to table 2, and mark table 1 as inactive. Now, production starts to read from table 2, and table 1 can be emptied any time. No downtime is required.
Hint: Clean/Dirty magnets don't help in the software example. Instead, you will need a global flag in database or application to indicate which table is active.
Grand Opening! The Software Bistro
Outside my family, two things I simply spend most time and energy on are - software engineering and fine food.
What I want to show you in my instantaneous thoughts on this blog is that they have great synergies, they are tightly connected, and they share the same philosophy.
For one, they both require experience and practice. Nobody intuitively knows when to propagate an exception and when to catch it, until he has tried and perhaps failed for many times; similarly, you need to eat and experience multiple times to be able to appreciate a particular combination of ingredients or flavors. They don't come instantly. The more you are into it, the better you are.
Then, they are both inspirational. You can never settle for the second best once you have tasted the best. For software, once you learn it's a hack, you can't sleep until you rewrite it in the elegant way; you always come back to your favorite restaurant and keep ordering the same dish because they make it better than the other places.
They are also intriguing. You spend the whole night at debugging and problem, when it finally unfolds itself, you are filled with satisfactory; you have the great expectation on a new restaurant, and when you take your first bite, ar ha!
Hope you will like my strange ideas on software engineering, and my gastronomy experiences.
What I want to show you in my instantaneous thoughts on this blog is that they have great synergies, they are tightly connected, and they share the same philosophy.
For one, they both require experience and practice. Nobody intuitively knows when to propagate an exception and when to catch it, until he has tried and perhaps failed for many times; similarly, you need to eat and experience multiple times to be able to appreciate a particular combination of ingredients or flavors. They don't come instantly. The more you are into it, the better you are.
Then, they are both inspirational. You can never settle for the second best once you have tasted the best. For software, once you learn it's a hack, you can't sleep until you rewrite it in the elegant way; you always come back to your favorite restaurant and keep ordering the same dish because they make it better than the other places.
They are also intriguing. You spend the whole night at debugging and problem, when it finally unfolds itself, you are filled with satisfactory; you have the great expectation on a new restaurant, and when you take your first bite, ar ha!
Hope you will like my strange ideas on software engineering, and my gastronomy experiences.
Subscribe to:
Posts (Atom)