I came accross an interesting study that indicates that verbal comminucation is far not the most effective way of coneying information. It turned out that our emotions and gestures can be more informative than words.
Here is the excerpt from the source:
"One study at UCLA indicated that up to 93 percent of communication effectiveness is determined by nonverbal cues. Another study indicated that the impact of a performance was determined 7 percent by the words used, 38 percent by voice quality, and 55 percent by the nonverbal communication."
Read more at: http://humanresources.about.com/od/interpersonalcommunicatio1/a/nonverbal_com.htm.
Monday, July 20, 2009
Automated tests: the sooner the better!
This is the most impressive experience I gained in my entire professional career. Read on and you will probably find it worth of trying.
Several years ago we faced the need to dramatically increase test automation coverage. Let the reasons be aside for now and let's focus on the problem per se. We had complex UI-driven software, full of custom controls and volatile UI elements changed from release to release. Our experience in test automation was refrained to the collection of several hundred tests that we occasionally used for smoke and regression testing. In order to get where we needed to be we had to automate ten thousand tests in a very short period of time, 1-2 years.
At the first glance the problem had no solution. It was really hard to be in that situation, when you see no way out. But we started the project having no idea if it's going to be successful. We started from optimizing of what we already can do, divided team in two sub-teams (one team focused on test design and manual execution, another took responsibility for test automation). We also introduced all the best practices that helped us to keep test production and maintenance cost low.
But this was not enough. Automation team was always behind testing process because they needed time to implement and debug test code on a working system. With insignificant exceptions, so, we could not use automated tests for functional test execution during the production cycle. We could only use it for regression testing of future versions. Tests still needed to be executed manually at least once. It had severe impact on testing schedule and drug us back because manual team was always on a critical path.
Then we’ve got an idea. It was as easy as it could only be. As far as implementation phase is what makes automation team fall behind we have to shorten it somehow. Adding resources is not an option. We already had several people working on this project and adding more people could severely increase overhead cost of communication. We went anther way.
Instead of adding resources we decided to move a part of test automation preparation task back in time, to do them in advance. We decided to do design of automated tests long before a working version is made available. Design means that we created fish bones of tests. Those tests used virtual functions that, when implemented, allow manipulating application features. Functions remained not implemented until we have a working version of a product in our hands. So, the tests could not be debugged until that time. But the most of design work is already done. And our experience indicated that this part is very significant.
When a new version of application comes to testing, automation engineers started implementation phase. They simply added code to the helper functions to make the test work. After that they run and debugged tests.
I will demonstrate how it worked in example:
1. We need to test a web search system that allows users to run the search, browse results and bookmark interesting findings.
2. Automation engineers select tests for automation. For example they have selected the following tests:
a. Different types of queries ("", "my search", "very-very-very long string").
b. Browse results (pages 1 through 10).
3. Automation team has steps of tests and test data defined in the test description created by manual team. So, thy create test architecture design like this:
test 1 - Different types of queries
test01_Search (String query, Integer expected) {
login();
doSearch(query);
assertEqual(getResults().totalCount, expected);
}
Used functions login(), doSearch(), and getResults() are not implemented so far! We have only figured out which functions we will need to enable our tests work.
Note: In order to do it safely it is recommended to insert a string of code that will fail your tests until function is not implemented, like this:
function doSearch(String query) {
fail('Not implemented');
}
Test that go through pages of results could be looking like follows:
test02_Paging (String query, Integer expected) {
String[] pageTokens = {"page1", ..."page 10"};
login();
doSearch(query);
for (int i=1; i<=10; i++) {
goToPage(i);
assertEqual(getPageToken(), pageTokens[i]);
}
}
Same way we can Design all tests that we selected for automation in advance. Thus we are saving this time from implementation and shorten the duration of automation. As practice had shown we can save up to 50% of time allocated for test automation. Roughly assessing, design phase is accounted for a half time allocated for the automation. So we shorten the second phase in a half, allowing automated tests to be ready sooner in the testing cycle.
Using this technology we have achieved the ratio of tests executed manually and automatically 1:1. This means that only a half of tests were executed manually each new release. Another half of tests were executed as automated right away. This had greatly increased automation ROI because we had no need to execute them manually at all and saved up to 40% of manual testing resources each release. Additionally, automated tests could be used for in-project regression testing much earlier. It also helped to get much of benefit from the idea.
In general, this approach had completely changed the role automated testing played in our project, making it at least as important and effective as manual testing.
Hope this helps making your test automation effort more fun! :) Feel free to comment should you have questions on details of implementation or should you have risks that may prevent you from having it work for you.
Several years ago we faced the need to dramatically increase test automation coverage. Let the reasons be aside for now and let's focus on the problem per se. We had complex UI-driven software, full of custom controls and volatile UI elements changed from release to release. Our experience in test automation was refrained to the collection of several hundred tests that we occasionally used for smoke and regression testing. In order to get where we needed to be we had to automate ten thousand tests in a very short period of time, 1-2 years.
At the first glance the problem had no solution. It was really hard to be in that situation, when you see no way out. But we started the project having no idea if it's going to be successful. We started from optimizing of what we already can do, divided team in two sub-teams (one team focused on test design and manual execution, another took responsibility for test automation). We also introduced all the best practices that helped us to keep test production and maintenance cost low.
But this was not enough. Automation team was always behind testing process because they needed time to implement and debug test code on a working system. With insignificant exceptions, so, we could not use automated tests for functional test execution during the production cycle. We could only use it for regression testing of future versions. Tests still needed to be executed manually at least once. It had severe impact on testing schedule and drug us back because manual team was always on a critical path.
Then we’ve got an idea. It was as easy as it could only be. As far as implementation phase is what makes automation team fall behind we have to shorten it somehow. Adding resources is not an option. We already had several people working on this project and adding more people could severely increase overhead cost of communication. We went anther way.
Instead of adding resources we decided to move a part of test automation preparation task back in time, to do them in advance. We decided to do design of automated tests long before a working version is made available. Design means that we created fish bones of tests. Those tests used virtual functions that, when implemented, allow manipulating application features. Functions remained not implemented until we have a working version of a product in our hands. So, the tests could not be debugged until that time. But the most of design work is already done. And our experience indicated that this part is very significant.
When a new version of application comes to testing, automation engineers started implementation phase. They simply added code to the helper functions to make the test work. After that they run and debugged tests.
I will demonstrate how it worked in example:
1. We need to test a web search system that allows users to run the search, browse results and bookmark interesting findings.
2. Automation engineers select tests for automation. For example they have selected the following tests:
a. Different types of queries ("", "my search", "very-very-very long string").
b. Browse results (pages 1 through 10).
3. Automation team has steps of tests and test data defined in the test description created by manual team. So, thy create test architecture design like this:
test 1 - Different types of queries
test01_Search (String query, Integer expected) {
login();
doSearch(query);
assertEqual(getResults().totalCount, expected);
}
Used functions login(), doSearch(), and getResults() are not implemented so far! We have only figured out which functions we will need to enable our tests work.
Note: In order to do it safely it is recommended to insert a string of code that will fail your tests until function is not implemented, like this:
function doSearch(String query) {
fail('Not implemented');
}
Test that go through pages of results could be looking like follows:
test02_Paging (String query, Integer expected) {
String[] pageTokens = {"page1", ..."page 10"};
login();
doSearch(query);
for (int i=1; i<=10; i++) {
goToPage(i);
assertEqual(getPageToken(), pageTokens[i]);
}
}
Same way we can Design all tests that we selected for automation in advance. Thus we are saving this time from implementation and shorten the duration of automation. As practice had shown we can save up to 50% of time allocated for test automation. Roughly assessing, design phase is accounted for a half time allocated for the automation. So we shorten the second phase in a half, allowing automated tests to be ready sooner in the testing cycle.
Using this technology we have achieved the ratio of tests executed manually and automatically 1:1. This means that only a half of tests were executed manually each new release. Another half of tests were executed as automated right away. This had greatly increased automation ROI because we had no need to execute them manually at all and saved up to 40% of manual testing resources each release. Additionally, automated tests could be used for in-project regression testing much earlier. It also helped to get much of benefit from the idea.
In general, this approach had completely changed the role automated testing played in our project, making it at least as important and effective as manual testing.
Hope this helps making your test automation effort more fun! :) Feel free to comment should you have questions on details of implementation or should you have risks that may prevent you from having it work for you.
Friday, July 17, 2009
Team or group?
I heard the opinion that most of work units that we used to call teams are actually groups. One of important team's features is having universal performers, so as if one person is out the work can still be done by another. This is not a case for the groups, when people tend to specialize in some area. Replacing such key people with other is always a problem because the knowledge and skills they accumulated are unique and it takes time to train someone else.
Another difference between teams and group is structure. Teams do not have defined leaders; there are no superior and inferior members.
Modern software developer processes tend to favor teams over groups. Agile encourages cross-training, sharing goals and discourages traditional management practices because they divide people into “us” and “them”.
So, what is better? I can't say for sure because the answer will depend on what you are trying to achieve, who work for you and the way people are motivated. If you can share the success of a project evenly then it would be great to have a team. If there are different levels of responsibility defined and if shares will depend on those levels then you need to stick to group organization.
I am sure that if done rightly teams and groups can be similarly successful.
Another difference between teams and group is structure. Teams do not have defined leaders; there are no superior and inferior members.
Modern software developer processes tend to favor teams over groups. Agile encourages cross-training, sharing goals and discourages traditional management practices because they divide people into “us” and “them”.
So, what is better? I can't say for sure because the answer will depend on what you are trying to achieve, who work for you and the way people are motivated. If you can share the success of a project evenly then it would be great to have a team. If there are different levels of responsibility defined and if shares will depend on those levels then you need to stick to group organization.
I am sure that if done rightly teams and groups can be similarly successful.
Tuesday, July 14, 2009
Personal performance monitoring and management
We all see the world with obscure eyes. We believe that people around us think and act same way as we do. The truth is that we are all different. What we see to be a problem can be accepted by another person as a normal behavior. The art of team performance management is in making all facts of misbehavior noted and corrected.
The first step on this path is giving another perspective to a person. For the sake of experiment ask your manager to jog down 3 strengths and 3 weaknesses in your professional behavior. Most probably you'll be surprised with results. The difference comes from different mindset, different criteria of assessment and different priorities used by you and your manager. Having a look from the outside is always helpful in determining where to direct your self-improvement.
Performance appraisals are written to provide independent, unbiased, and detailed enough perspective of someone's achievements, strengths, and weaknesses. It helps looking at all these things through the prism of another system of values. The best result is achieved is the system of values not that of a manager but that of a team. This is not as easy because performance appraisals are written by managers. But this is possible.
In order to define proper system of values, or a measure, you need to define what your team needs more in order to reach its goals. Find out qualities, which, if excelled by individuals, will get you closed to the goal. Here is my list, for example:
- Qualification
- Quality of work
- Quantity of work
- Responsibility
- Timeliness (ability to meet deadlines)
- Communication
- Initiative
- Creativity
- Flexibility
- Learning from mistakes
You may use this or you define your own list of qualities. It works best if defining such a list is a collective effort.
After we defined the list of qualities you may start giving marks to team members. Most of errors in implementation are made at this stage. Managers who perform assessment may provide subjective mark that does not only serve the purpose badly, it also may be counter-productive. There is no mistake worse in the management than under-valuing someone. People feel such things very keenly and take it very closely.
So, in order to use a team-oriented system of values we need to collect information from the team. Ask peers to fill in assessment form for a person. In parallel, write your own assessment and them compare one against another. And not only that... The difference you find should be explained!
Once you have finished adjustment, you are ready to write an unbiased team oriented assessment. While writing it keep in mind that you may face resistance to accept some things in it o the side of a person, who is the subject to the appraisal. Make sure it has examples of good and bad behavior highlighted in it. If you have difficulties in remembering such examples, ask your peer reviewers to provide them.
Reading appraisal to a person is another possibility to screw it up. Do not make it painful. Explain that the reason of it is to help your team mate to grow, to improve. Make him or her feeling comfortable with a joke or two. But do not go too far. Do not make look like a farce. This is a serious business, a team's priority one.
While describing and reading assessment start from the positive achievements like this: "You did very well at writing ABC driver. It was a complex task, new to you. Anyway you performed it on a very high professional level. However, the depth of testing was not enough. The defects discovered after you by testers where mostly of unit type. A least 10 of 15 defects could have been removed if you performed unit testing well enough".
And the last but not least, the marks! What is it going to be? I prefer qualitative marks:
- Superior
- Sufficient
- Insufficient
Superior means that a person can be an example for others on the team. Sufficient and Insufficient speak for themselves.
Such marks can be set against qualities for your team mates and can be used in team ranking or even for comparing your team's people against other teams in the company. In result of such comparison one may come up with enterprise level ranking for all employees - a dream of every CEO :)
Hope this helps and have a nice assessment!
The first step on this path is giving another perspective to a person. For the sake of experiment ask your manager to jog down 3 strengths and 3 weaknesses in your professional behavior. Most probably you'll be surprised with results. The difference comes from different mindset, different criteria of assessment and different priorities used by you and your manager. Having a look from the outside is always helpful in determining where to direct your self-improvement.
Performance appraisals are written to provide independent, unbiased, and detailed enough perspective of someone's achievements, strengths, and weaknesses. It helps looking at all these things through the prism of another system of values. The best result is achieved is the system of values not that of a manager but that of a team. This is not as easy because performance appraisals are written by managers. But this is possible.
In order to define proper system of values, or a measure, you need to define what your team needs more in order to reach its goals. Find out qualities, which, if excelled by individuals, will get you closed to the goal. Here is my list, for example:
- Qualification
- Quality of work
- Quantity of work
- Responsibility
- Timeliness (ability to meet deadlines)
- Communication
- Initiative
- Creativity
- Flexibility
- Learning from mistakes
You may use this or you define your own list of qualities. It works best if defining such a list is a collective effort.
After we defined the list of qualities you may start giving marks to team members. Most of errors in implementation are made at this stage. Managers who perform assessment may provide subjective mark that does not only serve the purpose badly, it also may be counter-productive. There is no mistake worse in the management than under-valuing someone. People feel such things very keenly and take it very closely.
So, in order to use a team-oriented system of values we need to collect information from the team. Ask peers to fill in assessment form for a person. In parallel, write your own assessment and them compare one against another. And not only that... The difference you find should be explained!
Once you have finished adjustment, you are ready to write an unbiased team oriented assessment. While writing it keep in mind that you may face resistance to accept some things in it o the side of a person, who is the subject to the appraisal. Make sure it has examples of good and bad behavior highlighted in it. If you have difficulties in remembering such examples, ask your peer reviewers to provide them.
Reading appraisal to a person is another possibility to screw it up. Do not make it painful. Explain that the reason of it is to help your team mate to grow, to improve. Make him or her feeling comfortable with a joke or two. But do not go too far. Do not make look like a farce. This is a serious business, a team's priority one.
While describing and reading assessment start from the positive achievements like this: "You did very well at writing ABC driver. It was a complex task, new to you. Anyway you performed it on a very high professional level. However, the depth of testing was not enough. The defects discovered after you by testers where mostly of unit type. A least 10 of 15 defects could have been removed if you performed unit testing well enough".
And the last but not least, the marks! What is it going to be? I prefer qualitative marks:
- Superior
- Sufficient
- Insufficient
Superior means that a person can be an example for others on the team. Sufficient and Insufficient speak for themselves.
Such marks can be set against qualities for your team mates and can be used in team ranking or even for comparing your team's people against other teams in the company. In result of such comparison one may come up with enterprise level ranking for all employees - a dream of every CEO :)
Hope this helps and have a nice assessment!
Ho to obtain good estimates?
Today, we will speak about eliciting estimates from people. It would make the task easier if your peers who oppose you in this matter would read "how to make good estimates?" first. Even if they didn't this is in your hands to lead them the right path.
First of all make sure the task is understood by the performer. Ask him or her to paraphrase the assignment to you, so you can correct it until it's too late. This is also important to help the performer understand what other task performed in the past could be used for comparison or verification of the estimate. Sit down together and find what you did before that can be measured up against a new task (similar project, task). However, be careful to use examples more than 3 times bigger or smaller in size.
If you don't have examples and the task is completely new to a performer then define the plan how to analyze the problem (investigation, prototyping, consulting gurus, etc.). One of most important parts of this stage is having a concrete goal, a milestone when the investigation will complete, or at least a date of its completion will be known.
Once you have got first estimate do not accept it as is. Question it. People tend to take estimates too optimistic, so they have troubled in meeting them afterwards. In order not to fall prey of wishful thinking, start asking "what if?" question. What is that part will not be delivered to you for testing at the date you assumed? What is if it will take longer to test your code? I have seen that testing of such modules takes up to 30% of development time. What if you have no product requirements finished at the desired date? What else you can do to mitigate that risk? Asking such questions will help you analyze different scenarios of "how it may go wrong". Such scenarios are usually neglected by people who used to think overly optimistically.
This is also helpful to build your own estimates or to ask another expert to provide a variant of the estimation. Comparing alternatives is a key to finding out what is missed from consideration. Creating estimates using different parameters is another way of drawing alternatives for the analysis (calculate time needed to test out of development hours vs. the same parameter calculated from the number of requirement). Never use average, or some percent of several estimates. This is completely wrong because our goal is to find why the estimates are different, so we can correct them with new information that has been missed from consideration during the initial estimation.
This is it! It's pretty easy and straightforward process :)
As for the methods of estimation I recommend you reading "How much does a project cost?" by Steve McConnel.
First of all make sure the task is understood by the performer. Ask him or her to paraphrase the assignment to you, so you can correct it until it's too late. This is also important to help the performer understand what other task performed in the past could be used for comparison or verification of the estimate. Sit down together and find what you did before that can be measured up against a new task (similar project, task). However, be careful to use examples more than 3 times bigger or smaller in size.
If you don't have examples and the task is completely new to a performer then define the plan how to analyze the problem (investigation, prototyping, consulting gurus, etc.). One of most important parts of this stage is having a concrete goal, a milestone when the investigation will complete, or at least a date of its completion will be known.
Once you have got first estimate do not accept it as is. Question it. People tend to take estimates too optimistic, so they have troubled in meeting them afterwards. In order not to fall prey of wishful thinking, start asking "what if?" question. What is that part will not be delivered to you for testing at the date you assumed? What is if it will take longer to test your code? I have seen that testing of such modules takes up to 30% of development time. What if you have no product requirements finished at the desired date? What else you can do to mitigate that risk? Asking such questions will help you analyze different scenarios of "how it may go wrong". Such scenarios are usually neglected by people who used to think overly optimistically.
This is also helpful to build your own estimates or to ask another expert to provide a variant of the estimation. Comparing alternatives is a key to finding out what is missed from consideration. Creating estimates using different parameters is another way of drawing alternatives for the analysis (calculate time needed to test out of development hours vs. the same parameter calculated from the number of requirement). Never use average, or some percent of several estimates. This is completely wrong because our goal is to find why the estimates are different, so we can correct them with new information that has been missed from consideration during the initial estimation.
This is it! It's pretty easy and straightforward process :)
As for the methods of estimation I recommend you reading "How much does a project cost?" by Steve McConnel.
Monday, July 13, 2009
How to make good estimates?
All of us faced the problem of giving estimates. The problem here is that sooner or later we have to meet the milestones planned out of our estimates. When we can't - we get our due portion of frustration from managers.
Estimation is a projection. In order to do it precisely you need to know of the task as much as possible in advance. If a task is new to you then you hardly be able to predict all the details with due preciseness. Best estimates are made for the task that we know well. The more we know of the task, the more precise our estimate can be.
We can compare the task against other known task we performed in the past or we can just use our experience with similar tasks. If we never did anything alike before then it makes sense to do research or a sample that will provide you with clues on how long it make take. For example, you need to translate all the code from Visual Basic into .NET but you didn't do that before. Before giving estimates, you can select some piece of code for a sample, port it to .NET and extrapolate the result to the whole bunch of code.
Estimate is the measure to something that did not happen yet. When we talk about future we always consider different variants how things may go. Many defects created by newbie, new development environment or even power supply may bring us some surprises. As far as we assume and measure future, every estimate implies probability. Point estimate (like 8 or 10 days) has almost 100% probability to fail (because the actual work can take 7.5 days or 11 days). So, this is not very unwise to give point estimates. Make it a range and share your vision on probability. Whatever you chose for a range of values it should be big enough to make you confident you can make it.
For example, if I would be asked to provide estimate on the weight of a space ship (that I have no idea about) I would provide a very rough estimate. Rough means that the range would be really big (50 to 200 tons).
Rough estimates are not what will make your manager happy. Actually he or she will be a bit confused and perplexed by it. They can't use it for planning. To resolve his or her confusion you need to express what you are going to do about it. Tell your manager what other information or what prototyping or online investigation you have to do to learn more about the problem.
As I have written above, the more we learn of the task the more precisely we can project on its pace and timing. Do not hesitate to ask for help. Managers can also be useful ;) They can help you finding the required hardware or procure tools. They can even suggest who to ask for the consultation on a specific problem. Inform you manager what else you need to learn about the task before you can make a more precise estimate. Also, mention when you can revise your estimate so a manager can adjust his or her plans accordingly.
A good estimate may undergo several revisions before it becomes reliable. A reliable estimate is what you believe you can make almost for sure. "Almost" is for the contingencies that could hardly be predicted in advance (power down, system crash, network problems, illness of key people, etc.).
In order to improve, keep tracking the preciseness of estimates on different stages (project initiation, design, implementation, testing, and maintenance). Analyze deviations to find out what to focus on in the future. Achieving preciseness of 10% is considered really good.
Following these recommedation you will find out pretty soon that making estimates is not a pain but fun. Good luck!
P.S. Next post will be on how to elicit good estimates. Stay tuned!
Estimation is a projection. In order to do it precisely you need to know of the task as much as possible in advance. If a task is new to you then you hardly be able to predict all the details with due preciseness. Best estimates are made for the task that we know well. The more we know of the task, the more precise our estimate can be.
We can compare the task against other known task we performed in the past or we can just use our experience with similar tasks. If we never did anything alike before then it makes sense to do research or a sample that will provide you with clues on how long it make take. For example, you need to translate all the code from Visual Basic into .NET but you didn't do that before. Before giving estimates, you can select some piece of code for a sample, port it to .NET and extrapolate the result to the whole bunch of code.
Estimate is the measure to something that did not happen yet. When we talk about future we always consider different variants how things may go. Many defects created by newbie, new development environment or even power supply may bring us some surprises. As far as we assume and measure future, every estimate implies probability. Point estimate (like 8 or 10 days) has almost 100% probability to fail (because the actual work can take 7.5 days or 11 days). So, this is not very unwise to give point estimates. Make it a range and share your vision on probability. Whatever you chose for a range of values it should be big enough to make you confident you can make it.
For example, if I would be asked to provide estimate on the weight of a space ship (that I have no idea about) I would provide a very rough estimate. Rough means that the range would be really big (50 to 200 tons).
Rough estimates are not what will make your manager happy. Actually he or she will be a bit confused and perplexed by it. They can't use it for planning. To resolve his or her confusion you need to express what you are going to do about it. Tell your manager what other information or what prototyping or online investigation you have to do to learn more about the problem.
As I have written above, the more we learn of the task the more precisely we can project on its pace and timing. Do not hesitate to ask for help. Managers can also be useful ;) They can help you finding the required hardware or procure tools. They can even suggest who to ask for the consultation on a specific problem. Inform you manager what else you need to learn about the task before you can make a more precise estimate. Also, mention when you can revise your estimate so a manager can adjust his or her plans accordingly.
A good estimate may undergo several revisions before it becomes reliable. A reliable estimate is what you believe you can make almost for sure. "Almost" is for the contingencies that could hardly be predicted in advance (power down, system crash, network problems, illness of key people, etc.).
In order to improve, keep tracking the preciseness of estimates on different stages (project initiation, design, implementation, testing, and maintenance). Analyze deviations to find out what to focus on in the future. Achieving preciseness of 10% is considered really good.
Following these recommedation you will find out pretty soon that making estimates is not a pain but fun. Good luck!
P.S. Next post will be on how to elicit good estimates. Stay tuned!
Friday, July 10, 2009
Microsoft vs. Google
Growing net book market is what both MS and Google are targeting with their new operating systems. Both companies believe in their projections that this opportunity will grow significantly in the nearest time. Even now few can imagine what they can do with a computer without Internet.
MS is ahead but Google seems to be in better shape for a long race. Google controls a big part of Internet and it makes it easy to enter the market. So, MS brand and popularity will not be such a big deal. Google will also open codes of their system. They believe it will help closing the gap in number of software solutions available for their system pretty fast.
Besides Microsoft has an advantage on this market Google can singnificantly undermine their position on the market of OS for mobile Internet devices.
Anyways, it's going to be a triller. End users will inevitably win from this competition.
MS is ahead but Google seems to be in better shape for a long race. Google controls a big part of Internet and it makes it easy to enter the market. So, MS brand and popularity will not be such a big deal. Google will also open codes of their system. They believe it will help closing the gap in number of software solutions available for their system pretty fast.
Besides Microsoft has an advantage on this market Google can singnificantly undermine their position on the market of OS for mobile Internet devices.
Anyways, it's going to be a triller. End users will inevitably win from this competition.
Subscribe to:
Posts (Atom)