Myth 22 : A tester testing Globalization features need not pay any special attention towards testing MUI feature.
I had touched up the nuances of Multilingual user interface (MUI) feature in this post as well as this one in the past. These posts primarily focused on how MUI technology is implemented in Windows Operating systems and spoke about the differences in MUI technology in different versions of Windows OS. What these posts did not cover specifically about MUI was- if the software application you are testing supports Multilingual user Interface, then what are the aspects that you can look at from testing perspective to ensure that MUI is tested properly. In my experience, this is an often neglected area of Globalization testing. May be because supporting MUI is one of the basic features and it is often "expected" to be working fine just because few common user cases work. The purpose of this post is to correct this myth and look at the finer details of a typical MUI implementation and the areas the could be generally tested.
MUI at a basic level:
What does it actually mean why you stare at a requirement that says- the application you are testing supports MUI ?
At a very basic level, it means that-
1. In the application under test, the strings are separated from the source code. What does "Strings" include in an application ? Strings may include any text on User Interface (or even sometimes Command Line interface) such as Menu names, Text labels,Control names etc. All these are generally static texts, which are usually the candidates for translation into any given language. These strings are separated from the source code and included in the resource files.
2. The second part- at a higher level, of being an MUI supported application is that the application has the ability (built programatically) to load the separated resource files dynamically at the run time.
So MUI software application is the one which is language neutral, has the translatable strings available separately in the resource files and finally has the ability to load the resource files dynamically.
Lets further look into some questions that might come into mind at this time-
What is the need to separate the strings from the source code ?
If the strings are not separated from the source code, then it will reside in the source code. What that means is- the language experts who translate the strings to the target language wont have access to those strings as they usually get the strings in separate files (called resource files) to carry out the translation. In this situation, when the strings are still in source code- it will result in that text being shown in the base language even when the application is localized. e.g. suppose the application's original language is English and there is a requirement to translate in German. So, the strings residing in source code will not get translated in German and we will have part English and part German text because of some English strings still being "hard-coded".
The second question that might arise is-
What is the need to dynamically load the resource file ?
Few examples here-
- Suppose an application supports 3 languages- English, German and French. If user installs the application on German OS, then at the time of installation, the application should recognize the Germaan OS and load the German resource files. If it does not then the German customer may end up seeing English or French text.
- Suppose the organization has a support group in Germany and they deal with English customers. The German support engineer might prefer the User interface to be in German and as he is dealing with English customer, there may be a need for him to switch between German and English User interfaces. This is where dynamically loading the resources and hence, the MUI features comes in real handy.
What are the questions i should ask before testing MUI feature ?
Asking questions helps! and it does always help to ask quite a lot before testing and of course, while testing. Some questions below might help understanding the scope of MUI testing-
- Is the Installer of my application support MUI i.e. does the application Installer installs different supported languages' resource files as a part of Installation ? i.e. if product supports English, German and French languages- does the respective resource files gets into the system during installation ?
- Does the installer recognize the OS locale settings and installs appropriate resources files as per locale settings ?
- Does the application installer provides an option to select the language before proceeding with Installation ?
- Is the Fallback logic implemented ? i.e. say if supported language is German and the application is installed on Dutch OS, does the application falls back to a common language say English ?
- After the application is installed, does it provide the option to the user to switch language at a run time ? i.e.
- If the computer has 2 users with different languages (its possible in Windows OS!) i.e. say English and German and the user logs on to German user settings, does the application desplays the German UI ? This should be taken care of by the application's dynamic resource loading logic.
- If the application happens to be a web application, then too all the above questions will hold good. One additional question to ask, though can be- What is user's browser language ? This is a typical case- when OS language is different from the browser language. In this case, what is the fallback logic ? How should it behave ? It can become more complex say in a situation when the web application runs on French OS with French Canadian browser settings and at the application logon page, the user selects English language as his preferred language. In this case, what language should be shown to the user ?
- How does the MUi logic works in Mac, Linux, Firefox, Mozilla etc. ? Are there any implementation differences that i need to be aware of ?
These questions (and may be more) can help clarify MUI requirement in detail and accordingly testing strategy can be formed. Asking questions is required because Test engineers may never get the requirements in as much detail as might be required for them to test effectively.
Why is testing MUI feature important ?
For an International application, MUI is one of the key features. It is a feature that has helped Microsoft add the required scalability to scale their products across the world. The reason i used Microsoft's example here is because probably Microsoft is the most Global software organization in the entire world. Consider this- Windows 98 supported 30 languages, Windows XP supported 42 languages and Windows Vista- a whopping 97 languages. One of the prime reasons, Microsoft has been able to scale up so much in Windows Vista is because of advancement in MUI technology during the Vista release and this technology is further used in Windows 7 too. So, for an application to be truly global, it has to have a core global arhitecture in place which is what MUI helps achieve.
What are typical Test ideas of Testing MUI feature in the application ?
At the core level, testing MUI means-
- Testing for Language neutral core binary
- Testing for single MUI Installation
- Testing for switching language without Reinstallation
- Testing for the logic of dynamically loading resources
- Testing for language Fallback mechanism
- Testing for Single base binary
Depending upon the answer to the questions asked in the section above, the right testing strategy can be formed.
I think with this information, i will be good to continue the discussion further on what parts of MUI can be specifically tested in your applications.
Please do share your ideas!
Friday, March 19, 2010
Saturday, March 13, 2010
Key professional lessons from Football coaching principles
In football circles, the mention of Don Shula doesnt need any introduction. He was a coach par excellence of Miami Dolphins in American National Football League (NFL). What stands him apart from most of other generations of Football coaches is sustained success in pressure cooker situations. If you have any doubts about what a pressure cooker situation means with respect to Football, just watch any high intensity international or even European club level matches to get an idea. Maddening crowds, Sharp critics, tensed coaches- it has all the elements of a nerve wrecking drama. In such an environment, Shula set numerous records in his 33 seasons as a head coach. He is the All-Time leader in Victories with 347. He is first in most games coached (526), most consecutive seasons coached (33) and many more.
His coaching was regarded as out of the world and to top it all his consistency in achieving super results over the years set many standards which are hard (if not impossible) to match.
Don Shula teamed up with Ken Blanchard to write an impressive book on coaching called the little book of coaching . This book is quite unique in its writing style as Don Shula shares his Football coaching methods that helped him achieve all the results that he did and Ken Blanchard on the other hand, presented his understanding of those very principles and utilized in day to day dealing. The content of this book is engaging and for sure opens up many a thought processes and the text that follows represents my attempt to decipher these valuable coaching fundamentals and its potential use in coaching Software testers-
[The text in Italics below represents the excerpts from the book, mainly in the form of quotes from Don Shula]
The Bull's eye philosophy:
I believe if you want to hit a target, you should aim for the Bull's eye. If you aim for the Bull's eye and miss, you will still hit the target. But if you are aiming only for the target and miss, you will be nowhere.
In 1972 NFL season, Don Shula's team won each and every game and remained unbeaten. And this was the goal that he set for his team.
While leading your testing teams, have the highest goals set for your team. As an example- say finding all the non regression bugs by the first iteration of testing as one the goals. If testers know this to be as their goal, they will strive to achieve this (of course if provided with the right kind of motivation). But if the goal stands like- Find all the non regression defects by the first Release candidate build, it is very likely that there will be last minute bugs before the release.
As a coach, always describe the vision of Bull's eye to your teams. More often than you might think, the team members do not know or have a clearer picture of how a perfect work output looks like. And in absence of such a vision, they adopt for a relaxing, comfortable goal that will invariably make them complacent. Drawing the vision of Bull's eye does not require one to be a magician but requires two things- One- clarity of thoughts i.e. first knowing what a perfect work output is like and Second- Ability to weave the picture of perfection for the team members, which they can strive to achieve. More the team strives to achieve the Bull's eye vision, more closer will it reach to perfection.
As Leo Burnett rightly quoted-
"If you reach for the stars, you might not quite get one, but you won’t end up with a handful of mud, either."
Overlearn, Overlearn, Overlearn...:
Overlearning means that the players are so prepared for a game that they have the skill and confidence needed to make the big play. More than anything else, overlearning- constant practice, constant attention to getting the details right everytime- produces hunger to be in the middle of the action. Perfection happens only when the mechanics are automatic.
As a coach of a Software testing, it pays to have your team reach the "Overlearning" state. Overlearning for Software testers cover many critical aspects of the Job-
- The testers are aware of their prime roles in the current project/scheme of things.
- The testers are trained so adequately that they almost simulate and visualize the situations and their response to it.
- The testers work independently as they strive to reach the auto-pilot mode i.e. not needing minor directions.
- The testers achieve Execution excellence- they dont just stare up the steps but step up the stairs.
The above areas form the core of activities for a Software testing coach also as these are the ones that actually are the difference between an average team and a performing team. The coach would need to Overlearn themselves first and then have their teams follow the suit.
Lead by Example:
I dont know any other way but lead by example.
During the 1994-95 season Don Shula ruptured his Achilles tendon. The day he had the operation was the first regular season practice Shula had missed in his twenty-five years with the Dolphins. After the operation, Don was taken to recovery and then to his hospital room, where he was scheduled to stay overnight. By 2:30 in the afternoon, he'd had enough of the hospital. He asked the doctor for his crutches and was on his way home shortly afterward. By 5:30 the next morning, he was up and wanting to attend Mass and then go to practice. By 10:00 A.M. he was on the practice field in a golf cart.
Moral of the story- if as a coach, if you expect commitment, demonstrate the same to your team. If you expect excellence, demonstrate the same to your team. The team wont learn anything in a better way than seeing you do the same very things you want them to do.
Change Plan as situation demands:
There is no point sticking to a game plan that's not working. The sun does not rise and fall based on one person's judgment. Effective coaches are continually out there scanning for data and advice that will make their decision more intelligent.
Software products probably undergo more changes during its entire life-cycle than any other products that ever existed. That really makes Software testing a very dynamic entity.
In spite of this, there is a growing tendency among the test owners to stick to a Testing Plan document that gets created at the start of the release and is probably never looked at through out the duration of the project. Effective Software testing coaches realize the importance of updating the overall plan as need arises and keep the team updated and informed. Such coaches can sense, anticipate the changes and be well prepared in advance.
Apply twenty-four hour rule equally to Failures and Successes:
I had a twenty-four hour rule. I allowed myself, my coaches, and our players a maximum of twenty-four hours after football game to celebrate a victory or bemoan a defeat. During that time, everyone was encouraged to experience the thrill of victory or the agony of defeat as deeply as possible, while learning as much as we could from that same experience. Once the twenty-four hour deadline had passed, we put it behind us and focused our energies on preparing for next opponent.
I feel this rule is very much applicable to handle mistakes and errors at workplace. Not all days are similar, there may be some days you do well and at other you end up doing mistakes. A typical bad day at office for a Software tester can be- Missing a deadline, missing to find a bug that could have been found earlier, committing an error in verifying a test properly, missing to gather right information to advocate defect appropriately and many more. Many people let these disappointments affect them and future work tasks severely. I think the role of a coach becomes greater and significant during these situation. Enforcing a twenty-four hour rule can be immensely beneficial in these situations i.e. for twenty four hours feel the current situation as much as possible and to an extent to learn from it enough not to repeat it excessively and after twenty fours- like they say- "let bygones be bygones".
Personally, i dont think the successes should also be lived only for twenty-four hours as more they are remembered in a right way (not losing the focus on present), it acts as a positive source of energy for the team members.
Be consistent:
Consistency is not behaving the same way all the time; it is behaving the same way in similar circumstances.
People generally have varying notions of consistency. Generally speaking, if as a coach you give no response/feedback to your team member when he or she does well and you neither give response/feedback when he or she commits a mistake- then thats not consistency. Though the conventional wisdom will call such a behavior consistent because as a coach one acted the same way in both the situations. As Shula clarifies, Consistency is actually behaving the same way in similar circumstances.
Withholding feedback when it should be given and not praising an effort when it should be applauded are an example of coach being inconsistent with his team members.
Consistent coaches deliver consistent results.
Personally notice your team:
You cant catch your people doing something right if you're not there to see them do something right.
People appreciate praise more when its genuine. A coach can be genuine in expressing his praise for the team only when he or she witnesses it firsthand. If as a Software testing coach, you are not there to directly witness your team member logging that all important bug or delivering a great presentation or convincing a developer, you are for sure not up-to-the-mark there.
Being personally there with the team when they are in pressure situations or not even in so much pressure situations gives them a belief that they can look upto you and also that you will be fair with them in performance related dealings.
Managing meetings effectively:
I want to make sure that my team came out of every meetings a little more intelligent than when they went in, that they came off the practice field a little better prepared mentally and physically to play the game than they were before the practice.
In the corporate world, meetings are for sure necessary evils. Organizations need meetings to synergize, sync-up and work towards the shared vision. But at the same time most of the meetings turn out to be ineffective with a very little takeaway for all the stakeholders. Below is an interesting nugget from this source about the way meetings are conducted in US corporations-
"More often than not, company and department meetings are inefficient, disorderly and ineffective. Every day, approximately 11 million meetings are held in the United States. That means roughly 37 percent of employee time is spent in meetings, according to the National Statistics Council. What's more, researchers have found that nearly all meeting attendees (91 percent) admit to daydreaming during meetings, while more than one-third (39 percent) have dozed off."
I think you would appreciate that the above inference is not only US specific but the rest of the world is not too far behind. Being a coach, Don Shula's thinking about ensuring that the team members should come out of the meeting little more intelligent and better is quite insightful. Even in the corporate meetings, the intent of meeting organizer is quite vital. This is where effective coaching can make a difference.
I feel as a coach of testing team or any team for that matter, if someone inculcates "making the team members more intelligent, more informed, more knowledgeable at the end of meeting" as a driving goal, we might probably see more happy faces and less dreamers during the day.
Do you already apply these principles in your coaching ? I would love to hear your thoughts.
His coaching was regarded as out of the world and to top it all his consistency in achieving super results over the years set many standards which are hard (if not impossible) to match.
Don Shula teamed up with Ken Blanchard to write an impressive book on coaching called the little book of coaching . This book is quite unique in its writing style as Don Shula shares his Football coaching methods that helped him achieve all the results that he did and Ken Blanchard on the other hand, presented his understanding of those very principles and utilized in day to day dealing. The content of this book is engaging and for sure opens up many a thought processes and the text that follows represents my attempt to decipher these valuable coaching fundamentals and its potential use in coaching Software testers-
[The text in Italics below represents the excerpts from the book, mainly in the form of quotes from Don Shula]
The Bull's eye philosophy:
I believe if you want to hit a target, you should aim for the Bull's eye. If you aim for the Bull's eye and miss, you will still hit the target. But if you are aiming only for the target and miss, you will be nowhere.
In 1972 NFL season, Don Shula's team won each and every game and remained unbeaten. And this was the goal that he set for his team.
While leading your testing teams, have the highest goals set for your team. As an example- say finding all the non regression bugs by the first iteration of testing as one the goals. If testers know this to be as their goal, they will strive to achieve this (of course if provided with the right kind of motivation). But if the goal stands like- Find all the non regression defects by the first Release candidate build, it is very likely that there will be last minute bugs before the release.
As a coach, always describe the vision of Bull's eye to your teams. More often than you might think, the team members do not know or have a clearer picture of how a perfect work output looks like. And in absence of such a vision, they adopt for a relaxing, comfortable goal that will invariably make them complacent. Drawing the vision of Bull's eye does not require one to be a magician but requires two things- One- clarity of thoughts i.e. first knowing what a perfect work output is like and Second- Ability to weave the picture of perfection for the team members, which they can strive to achieve. More the team strives to achieve the Bull's eye vision, more closer will it reach to perfection.
As Leo Burnett rightly quoted-
"If you reach for the stars, you might not quite get one, but you won’t end up with a handful of mud, either."
Overlearn, Overlearn, Overlearn...:
Overlearning means that the players are so prepared for a game that they have the skill and confidence needed to make the big play. More than anything else, overlearning- constant practice, constant attention to getting the details right everytime- produces hunger to be in the middle of the action. Perfection happens only when the mechanics are automatic.
As a coach of a Software testing, it pays to have your team reach the "Overlearning" state. Overlearning for Software testers cover many critical aspects of the Job-
- The testers are aware of their prime roles in the current project/scheme of things.
- The testers are trained so adequately that they almost simulate and visualize the situations and their response to it.
- The testers work independently as they strive to reach the auto-pilot mode i.e. not needing minor directions.
- The testers achieve Execution excellence- they dont just stare up the steps but step up the stairs.
The above areas form the core of activities for a Software testing coach also as these are the ones that actually are the difference between an average team and a performing team. The coach would need to Overlearn themselves first and then have their teams follow the suit.
Lead by Example:
I dont know any other way but lead by example.
During the 1994-95 season Don Shula ruptured his Achilles tendon. The day he had the operation was the first regular season practice Shula had missed in his twenty-five years with the Dolphins. After the operation, Don was taken to recovery and then to his hospital room, where he was scheduled to stay overnight. By 2:30 in the afternoon, he'd had enough of the hospital. He asked the doctor for his crutches and was on his way home shortly afterward. By 5:30 the next morning, he was up and wanting to attend Mass and then go to practice. By 10:00 A.M. he was on the practice field in a golf cart.
Moral of the story- if as a coach, if you expect commitment, demonstrate the same to your team. If you expect excellence, demonstrate the same to your team. The team wont learn anything in a better way than seeing you do the same very things you want them to do.
Change Plan as situation demands:
There is no point sticking to a game plan that's not working. The sun does not rise and fall based on one person's judgment. Effective coaches are continually out there scanning for data and advice that will make their decision more intelligent.
Software products probably undergo more changes during its entire life-cycle than any other products that ever existed. That really makes Software testing a very dynamic entity.
In spite of this, there is a growing tendency among the test owners to stick to a Testing Plan document that gets created at the start of the release and is probably never looked at through out the duration of the project. Effective Software testing coaches realize the importance of updating the overall plan as need arises and keep the team updated and informed. Such coaches can sense, anticipate the changes and be well prepared in advance.
Apply twenty-four hour rule equally to Failures and Successes:
I had a twenty-four hour rule. I allowed myself, my coaches, and our players a maximum of twenty-four hours after football game to celebrate a victory or bemoan a defeat. During that time, everyone was encouraged to experience the thrill of victory or the agony of defeat as deeply as possible, while learning as much as we could from that same experience. Once the twenty-four hour deadline had passed, we put it behind us and focused our energies on preparing for next opponent.
I feel this rule is very much applicable to handle mistakes and errors at workplace. Not all days are similar, there may be some days you do well and at other you end up doing mistakes. A typical bad day at office for a Software tester can be- Missing a deadline, missing to find a bug that could have been found earlier, committing an error in verifying a test properly, missing to gather right information to advocate defect appropriately and many more. Many people let these disappointments affect them and future work tasks severely. I think the role of a coach becomes greater and significant during these situation. Enforcing a twenty-four hour rule can be immensely beneficial in these situations i.e. for twenty four hours feel the current situation as much as possible and to an extent to learn from it enough not to repeat it excessively and after twenty fours- like they say- "let bygones be bygones".
Personally, i dont think the successes should also be lived only for twenty-four hours as more they are remembered in a right way (not losing the focus on present), it acts as a positive source of energy for the team members.
Be consistent:
Consistency is not behaving the same way all the time; it is behaving the same way in similar circumstances.
People generally have varying notions of consistency. Generally speaking, if as a coach you give no response/feedback to your team member when he or she does well and you neither give response/feedback when he or she commits a mistake- then thats not consistency. Though the conventional wisdom will call such a behavior consistent because as a coach one acted the same way in both the situations. As Shula clarifies, Consistency is actually behaving the same way in similar circumstances.
Withholding feedback when it should be given and not praising an effort when it should be applauded are an example of coach being inconsistent with his team members.
Consistent coaches deliver consistent results.
Personally notice your team:
You cant catch your people doing something right if you're not there to see them do something right.
People appreciate praise more when its genuine. A coach can be genuine in expressing his praise for the team only when he or she witnesses it firsthand. If as a Software testing coach, you are not there to directly witness your team member logging that all important bug or delivering a great presentation or convincing a developer, you are for sure not up-to-the-mark there.
Being personally there with the team when they are in pressure situations or not even in so much pressure situations gives them a belief that they can look upto you and also that you will be fair with them in performance related dealings.
Managing meetings effectively:
I want to make sure that my team came out of every meetings a little more intelligent than when they went in, that they came off the practice field a little better prepared mentally and physically to play the game than they were before the practice.
In the corporate world, meetings are for sure necessary evils. Organizations need meetings to synergize, sync-up and work towards the shared vision. But at the same time most of the meetings turn out to be ineffective with a very little takeaway for all the stakeholders. Below is an interesting nugget from this source about the way meetings are conducted in US corporations-
"More often than not, company and department meetings are inefficient, disorderly and ineffective. Every day, approximately 11 million meetings are held in the United States. That means roughly 37 percent of employee time is spent in meetings, according to the National Statistics Council. What's more, researchers have found that nearly all meeting attendees (91 percent) admit to daydreaming during meetings, while more than one-third (39 percent) have dozed off."
I think you would appreciate that the above inference is not only US specific but the rest of the world is not too far behind. Being a coach, Don Shula's thinking about ensuring that the team members should come out of the meeting little more intelligent and better is quite insightful. Even in the corporate meetings, the intent of meeting organizer is quite vital. This is where effective coaching can make a difference.
I feel as a coach of testing team or any team for that matter, if someone inculcates "making the team members more intelligent, more informed, more knowledgeable at the end of meeting" as a driving goal, we might probably see more happy faces and less dreamers during the day.
Do you already apply these principles in your coaching ? I would love to hear your thoughts.
Sunday, March 7, 2010
Key lessons from the life and times of Steve Jobs
I had completed reading the Book- Inside steve’s brain a while back. I found this book an excellent representation of the business lessons that can be learned from the life of Steven Paul "Steve" Jobs , the co-founder and chief executive officer of Apple Inc.
I have this inherent interest of going through the biographies of the people who have strived to excel in their chosen fields. (i could have used the word "Successful" in the previous sentence while describing the people who achieve something, but i tend to refrain from using that word because Success to me is very subjective, its very definition changes from people to people. I find Striving to Excel much meaningful representation here).
The prime driver of this interest is that there is a lot to learn from these people who had managed to do the seemingly unthinkable things. Books are simply a great medium which virtually help to connect to these people's lives and imbibe the learnings.
I have read quite a few biographies in the past and i would love to share my learnings through this medium.
This post is obviously all about Steve Jobs. Here are some detailed insights into what Steve Jobs is made up of-
Taking hard decisions head-on:
When Jobs took over as a CEO of Apple, he took a critical view of the situation at Apple. He arranged for each product group to present to him or rather virtually sell to him on the work they were doing, why it is important and why should be keep on funding them. In effective, the overall review process resulted in him taking some very tough decisions ranging from either the non critical projects being cut down or people being "steved" (meaning fired in Apple folklore).
He had to make some very hard tough decisions but he had courage and conviction to take them head-on rather than procrastinating or delaying them just because they were tough to make.
There is no official track on how much time human beings waste by just delaying some decisions just because they are uncomfortable but it were to be calculated, it would virtually run into zillions of hours wasted.
Facing hard decisions head-on is a vital quality for any decision maker.
Not hesitating to rightly say "No" when situation demands:
Steve Job's favorite mantra at Apple is: Focus means saying "No". When Apple first launched iMac, Jobs insisted on it not having a Floppy drive, which was an essential part of any computer of that era. It received a severe backlash from critics in the market with one of the critic even went ahead and declared-
"The iMac is clean, elegant, floppy free- and doomed."
As a fact of matter, Jobs himself wasn’t too sure about his decision to exclude the floppy drive given the odds stacked against him, But he still went ahead and said "No" to it trusting his gut. Also, the factors that helped him take this decision was the iMac was primarily supposed to be one of the early Internet computers and also that it was one of the first computers to be shipped with USB.
Whatever be the reasoning, it does take a tremendous mental effort to say "No" trusting your guts and knowledge when everyone else in the visible world is saying "Yes" to something. Many a professional situations demand that we say "No" but we end up saying "Yes" merely because of a feeling of lack of power on our part to reason the "Yes" men out. It does take a huge strength of character and belief in one's ability to be able to rightly say "No" when situation demands.
Focus on what you are good at; delegate all else:
Steve Jobs has a great sense of his strengths which is new product development, cutting deals for Apple (he is a master negotiator) and giving product presentations (which are flawless to say the least). At the same time, he knows what he is not good at- i.e. Directing movies, or handling the Wall Street or doing the Operations related tasks. His idea seems to be always playing to strength and take the advantage of the fact that there are people who can do the other jobs better than the way he could do. This aspect shows 2 points- One is the self awareness and second is not hesitating to admit that he cannot be good at everything. In professional life, there are many who have certain blind spots about themselves which prevent them to maximize their potential.
If one is not good at something, it often eases the work as well as the work relationships to actually delegate the tasks away. It is certainly not a sign of weakness.
Attention to details:
Steve Jobs is known for his obsession with details. As one of the design folks of Apple, Ratzlaff (who worked directly with Steve) says- "He was way down into the details. He would scrutinize everything, down to pixel level." He was so much so involved in the design that he had his own ideas how the seemingly minor thing such as Scrollbar should look like.
As goes one of the sayings- "God lies in detail", often the difference between a good job and a not-so-good job lies in the level of detail spent.
Never compromise with Excellence:
In Jan 1999, the day before the introduction of a new line of multicolored iMacs, Steve Jobs was practicing his product presentation at a big auditorium near Apple's HQ. Five of the machines in a range of bright colors were mounted on a sliding pedestal hidden behind the curtain, ready to take center stage on Jobs's cue.
Jobs wanted the moment when they slid out from behind the curtain to be projected onto a large video screen looming over the stage. The Technicians set it up, but Jobs didnt think the lighting was doing the translucent machine justice. The iMacs looked good onstage, but they didn’t really shine on the projection screen. He then kept asking the technician crew to alter the lighting till it looks just perfect. Finally, after the fourth attempt, they hit the bull’s eye and he was satisfied.
The above excerpt provide Jobs's commitment to Excellence. The key learnings from this is that one should marry Excellence in everything one does and then success becomes a mere formality.
Decision making through Intellectual combat:
Jobs makes decision by fighting about ideas. Its hard and demanding but rigorous and effective.
Though Jobs had a reputation of being a micro manager but he is smart enough to involve and engage people rightly to make worthwhile decisions.
The key learnings here- Never lose focus on the betterment of organization while making decisions. Involve people, look at an idea from all the possible directions. The idea for iPod’s scroll wheel came from Phil Schiller, the head of Apple’s marketing who was never a part of formal design process.
Dont Innovate for the sake of Innovation:
All about this here.
Dont be afraid of trial and error:
The typical design process at Apple goes through the myriad of trial and errors. Even the iPod's breakthrough interface was discovered through a process of trial and error. Such processes require a lot of perseverance and tolerance for mistakes but the end result is often a very refined one.
While indulging in any new task never hesitate to commit mistakes as long as one can learn and the output becomes close to perfection.
Well, these learnings are few of my chosen ones from this wonderful book.
I intend to supplement the series by sharing the learnings from biographies from other wonderful people. Watch out this space for more!
Thank you for reading through. I would love to hear any comments and feedback!
I have this inherent interest of going through the biographies of the people who have strived to excel in their chosen fields. (i could have used the word "Successful" in the previous sentence while describing the people who achieve something, but i tend to refrain from using that word because Success to me is very subjective, its very definition changes from people to people. I find Striving to Excel much meaningful representation here).
The prime driver of this interest is that there is a lot to learn from these people who had managed to do the seemingly unthinkable things. Books are simply a great medium which virtually help to connect to these people's lives and imbibe the learnings.
I have read quite a few biographies in the past and i would love to share my learnings through this medium.
This post is obviously all about Steve Jobs. Here are some detailed insights into what Steve Jobs is made up of-
Taking hard decisions head-on:
When Jobs took over as a CEO of Apple, he took a critical view of the situation at Apple. He arranged for each product group to present to him or rather virtually sell to him on the work they were doing, why it is important and why should be keep on funding them. In effective, the overall review process resulted in him taking some very tough decisions ranging from either the non critical projects being cut down or people being "steved" (meaning fired in Apple folklore).
He had to make some very hard tough decisions but he had courage and conviction to take them head-on rather than procrastinating or delaying them just because they were tough to make.
There is no official track on how much time human beings waste by just delaying some decisions just because they are uncomfortable but it were to be calculated, it would virtually run into zillions of hours wasted.
Facing hard decisions head-on is a vital quality for any decision maker.
Not hesitating to rightly say "No" when situation demands:
Steve Job's favorite mantra at Apple is: Focus means saying "No". When Apple first launched iMac, Jobs insisted on it not having a Floppy drive, which was an essential part of any computer of that era. It received a severe backlash from critics in the market with one of the critic even went ahead and declared-
"The iMac is clean, elegant, floppy free- and doomed."
As a fact of matter, Jobs himself wasn’t too sure about his decision to exclude the floppy drive given the odds stacked against him, But he still went ahead and said "No" to it trusting his gut. Also, the factors that helped him take this decision was the iMac was primarily supposed to be one of the early Internet computers and also that it was one of the first computers to be shipped with USB.
Whatever be the reasoning, it does take a tremendous mental effort to say "No" trusting your guts and knowledge when everyone else in the visible world is saying "Yes" to something. Many a professional situations demand that we say "No" but we end up saying "Yes" merely because of a feeling of lack of power on our part to reason the "Yes" men out. It does take a huge strength of character and belief in one's ability to be able to rightly say "No" when situation demands.
Focus on what you are good at; delegate all else:
Steve Jobs has a great sense of his strengths which is new product development, cutting deals for Apple (he is a master negotiator) and giving product presentations (which are flawless to say the least). At the same time, he knows what he is not good at- i.e. Directing movies, or handling the Wall Street or doing the Operations related tasks. His idea seems to be always playing to strength and take the advantage of the fact that there are people who can do the other jobs better than the way he could do. This aspect shows 2 points- One is the self awareness and second is not hesitating to admit that he cannot be good at everything. In professional life, there are many who have certain blind spots about themselves which prevent them to maximize their potential.
If one is not good at something, it often eases the work as well as the work relationships to actually delegate the tasks away. It is certainly not a sign of weakness.
Attention to details:
Steve Jobs is known for his obsession with details. As one of the design folks of Apple, Ratzlaff (who worked directly with Steve) says- "He was way down into the details. He would scrutinize everything, down to pixel level." He was so much so involved in the design that he had his own ideas how the seemingly minor thing such as Scrollbar should look like.
As goes one of the sayings- "God lies in detail", often the difference between a good job and a not-so-good job lies in the level of detail spent.
Never compromise with Excellence:
In Jan 1999, the day before the introduction of a new line of multicolored iMacs, Steve Jobs was practicing his product presentation at a big auditorium near Apple's HQ. Five of the machines in a range of bright colors were mounted on a sliding pedestal hidden behind the curtain, ready to take center stage on Jobs's cue.
Jobs wanted the moment when they slid out from behind the curtain to be projected onto a large video screen looming over the stage. The Technicians set it up, but Jobs didnt think the lighting was doing the translucent machine justice. The iMacs looked good onstage, but they didn’t really shine on the projection screen. He then kept asking the technician crew to alter the lighting till it looks just perfect. Finally, after the fourth attempt, they hit the bull’s eye and he was satisfied.
The above excerpt provide Jobs's commitment to Excellence. The key learnings from this is that one should marry Excellence in everything one does and then success becomes a mere formality.
Decision making through Intellectual combat:
Jobs makes decision by fighting about ideas. Its hard and demanding but rigorous and effective.
Though Jobs had a reputation of being a micro manager but he is smart enough to involve and engage people rightly to make worthwhile decisions.
The key learnings here- Never lose focus on the betterment of organization while making decisions. Involve people, look at an idea from all the possible directions. The idea for iPod’s scroll wheel came from Phil Schiller, the head of Apple’s marketing who was never a part of formal design process.
Dont Innovate for the sake of Innovation:
All about this here.
Dont be afraid of trial and error:
The typical design process at Apple goes through the myriad of trial and errors. Even the iPod's breakthrough interface was discovered through a process of trial and error. Such processes require a lot of perseverance and tolerance for mistakes but the end result is often a very refined one.
While indulging in any new task never hesitate to commit mistakes as long as one can learn and the output becomes close to perfection.
Well, these learnings are few of my chosen ones from this wonderful book.
I intend to supplement the series by sharing the learnings from biographies from other wonderful people. Watch out this space for more!
Thank you for reading through. I would love to hear any comments and feedback!
Wednesday, March 3, 2010
Uncovering myths about Globalization Testing- Finding Localization bugs before actual translation takes place
Myth 21: It is not possible to find the Localization bugs before actual translation takes place.
This is a myth because it is possible to find Localization bugs before actual translation takes place using an approach called- Pseudo Translation.
To know more visit my article on Pseudo Translation
Visit here to know about other Globalization Testing myths uncovered in the past.
This is a myth because it is possible to find Localization bugs before actual translation takes place using an approach called- Pseudo Translation.
To know more visit my article on Pseudo Translation
Visit here to know about other Globalization Testing myths uncovered in the past.
Subscribe to:
Posts (Atom)
