Dogfooding helps real world discovery of issues. But it also slants product features and tweaks to Use Cases that are overly specific to technologists as opposed to different use by every day laypeople. There should be broad parallels in use by different audiences in say Google Docs but in for example Google Photos, the Use Cases between in house programmers and the bulk of Photo Enthusiasts might be divergent
Dogfooding vs company centered software?... In some situations I prefer not-G software. How can you be aware of your limitations without contact with "reality"?
I have two questions: 1. How do you perform Dogfooding when you have product that is not used by internal teams? 2. What actions QA team takes when the bug is discovered in Dogfooding to prevent such a instances in future?
1. There are very few Google products that fall in this category, but the short answer is that we don't. We rely on testing, beta users, and public feedback. 2. When bugs are found during dogfooding, we improve our regular automated/manual test coverage to handle the cases.
Project plan, document, version and bug tracking is important for any software development organizations such as companies, communities and freelance developers.
Google products you mentioned above, really good and helpful.
I'm wondering any organization has distributed development teams (managing documents for different development teams/controlling/reporting) is how doing this track process by using Google's tools.
May be second book's name is "How Google manages a software?" and you could resolve my wonder with given samples in your book :-).
I think dog fooding should be complemented with "cat fooding". That is, using competitors' products. When you are limited to your own products, you might not realize how better the competing products are, at least in some aspects. For example, some fractions of the Windows team at MS should be forced to use OS-X.
Thanks for one more debatable post. Following are the inputs from my end.
Do you dogfood your company’s products? Yes, We do. Before releasing any product it is require to get the views from internal team as well. For example if a company is developing a bug tracking application and they are using third party software for logging application bugs then they will loose customer confidence and at some level they will reduce focus to their application as well. When we DogFood our application and share it for using it we get comments to improve it.
Do your office tools help or hinder your productivity? We divide the application usages from team to team so it does not hinder at any way.
What office software and tools do you find invaluable for your job? We use software from Word processor to project planning from project initialization to finish.
Could you use Google Docs/Sheets for large test plans? Have not tried but using it offline or where the internet access is not available is not a good choice.
I'm really curious to see how teams form at Google. Also, Google seems to have really good cross company/team communication. How does Google communicate good programming/testing practices to everyone? How does cross team pollination happen?
We communicate good practices in many ways: - Internal groups where we can ask the experts on topics like C++ or CSS. - Testing on the Toilet (some of these are posted externally on this blog) - Style guides - Test and development guides
In my day job, we use a real requirements management tool to manage test plans and the like: doing it with a spreadsheet and manual tracking just ain't fun, and I would not try doing it with Docs/Drive. But I am delighted to hear that you are using Sites.
Dogfooding helps real world discovery of issues. But it also slants product features and tweaks to Use Cases that are overly specific to technologists as opposed to different use by every day laypeople. There should be broad parallels in use by different audiences in say Google Docs but in for example Google Photos, the Use Cases between in house programmers and the bulk of Photo Enthusiasts might be divergent
ResponderEliminarDogfooding vs company centered software?... In some situations I prefer not-G software. How can you be aware of your limitations without contact with "reality"?
ResponderEliminarGoogle docs is a very important tool we use for development plans, and document related work. Dogfooding? we are getting there.
ResponderEliminarI have two questions:
ResponderEliminar1. How do you perform Dogfooding when you have product that is not used by internal teams?
2. What actions QA team takes when the bug is discovered in Dogfooding to prevent such a instances in future?
1. There are very few Google products that fall in this category, but the short answer is that we don't. We rely on testing, beta users, and public feedback.
Eliminar2. When bugs are found during dogfooding, we improve our regular automated/manual test coverage to handle the cases.
Project plan, document, version and bug tracking is important for any software development organizations such as companies, communities and freelance developers.
ResponderEliminarGoogle products you mentioned above, really good and helpful.
I'm wondering any organization has distributed development teams (managing documents for different development teams/controlling/reporting) is how doing this track process by using Google's tools.
May be second book's name is "How Google manages a software?" and you could resolve my wonder with given samples in your book :-).
I think dog fooding should be complemented with "cat fooding". That is, using competitors' products. When you are limited to your own products, you might not realize how better the competing products are, at least in some aspects. For example, some fractions of the Windows team at MS should be forced to use OS-X.
ResponderEliminarI agree. Dog fooding should be complimented with cat fooding.
ResponderEliminarHi Anthony,
ResponderEliminarThanks for one more debatable post. Following are the inputs from my end.
Do you dogfood your company’s products?
Yes, We do. Before releasing any product it is require to get the views from internal team as well. For example if a company is developing a bug tracking application and they are using third party software for logging application bugs then they will loose customer confidence and at some level they will reduce focus to their application as well. When we DogFood our application and share it for using it we get comments to improve it.
Do your office tools help or hinder your productivity?
We divide the application usages from team to team so it does not hinder at any way.
What office software and tools do you find invaluable for your job?
We use software from Word processor to project planning from project initialization to finish.
Could you use Google Docs/Sheets for large test plans?
Have not tried but using it offline or where the internet access is not available is not a good choice.
I'm really curious to see how teams form at Google. Also, Google seems to have really good cross company/team communication. How does Google communicate good programming/testing practices to everyone? How does cross team pollination happen?
ResponderEliminarWe communicate good practices in many ways:
Eliminar- Internal groups where we can ask the experts on topics like C++ or CSS.
- Testing on the Toilet (some of these are posted externally on this blog)
- Style guides
- Test and development guides
In my day job, we use a real requirements management tool to manage test plans and the like: doing it with a spreadsheet and manual tracking just ain't fun, and I would not try doing it with Docs/Drive. But I am delighted to hear that you are using Sites.
ResponderEliminar