Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Dog Food


Dog Food

Author
Message
noeld
noeld
SSCertifiable
SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)SSCertifiable (6.3K reputation)

Group: General Forum Members
Points: 6320 Visits: 2048
There is IMHO nothing like eating your own dog food to prove your clients how much you trust the product you sell. I know that not all cases are in the same situation but every company in the sofware business should try to do it as much as possible.



Cheers


* Noel
Katie Walker
Katie Walker
Grasshopper
Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)

Group: General Forum Members
Points: 17 Visits: 56
I have worked for companies that do use their own systems and ones that don't. I have found that everyone has their own idea of how the system should work. And they aren't always the same. Even after the site has been tested and retested, there is always someone who says, oh that's not what I meant. I meant this.



I do use a system that a client built, and I have found more bugs than they have. I have often teased that I should bill them for every bug I find. But I also realize that they test it the best that they can and sometimes things come up. We are all human and we are bound to make a mistake or two.



The biggest bug I ever found was when I worked for a physicians group. We were using software that another company had written. It was the fiscal end of year which ended June 30th. I ran my reports and discovered we were off by $34.50. My boss was very upset and demanded that I fix it. I tried everything I knew and I came up with that we were off by the cost of a flu shot. My boss wanted me to call the company and have them help me fix it. Of course it was 4th of July weekend and the company was off Monday the 3rd even though we weren't. I called Tech Support and my call was answered, but there was literally no one around to help. My boss didn't take that answer and eventually the VP of the softward company called me from the golf course. I explained that my boss wouldn't back off. The VP ended up talking to my boss who at that point was at the verge of firing me. We all came back Wed morning and a developer called me and they had it fixed by lunch. It was a bug that no one would have forseen unless they had set up the reports exactly as I had set them up.



Sometimes there are too many if, ands, or buts to figure out every possible way that a user might use the system. Even with a Quality Assurance Team, things still get out.
Ivan el terrible
Ivan el terrible
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
Points: 3 Visits: 12
Well problem is that majority of time the customers do not know what they want, so me and my team sit and develop a whole pipeline for months to come back when it’s done that they really not need that but the other and all the meetings and prototypes apparently I have been talking in vain. On data design, system architecture and all the rest I can do it in no time, but as soon as it comes to gui and workflows for it everybody has an opinion and every time it’s different. Last time after 5 people dedicated to ui workflow alone for 2-3 months, I sit down after it is released to find out that they are not using any of it and they just needed one simple thing, and our software does all but that not because it systematically not support it, but because of the workflow of the ui.
Tim OPry
Tim OPry
SSC-Enthusiastic
SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)SSC-Enthusiastic (160 reputation)

Group: General Forum Members
Points: 160 Visits: 247
As to the main question - Should companies 'eat their own dogfood' (use their own products) - absolutely. If they are not using their own but something else, then as a customer (or potential customer), I would likely ask them why I should not use that other product as well. (assuming they are comparative)



There are some pitfalls with doing this if you come to think of your internal user base as indicative/representative of your users in general. Normally, this would be inaccurate - unless your userbase is primarily other software development firms (unlikely for most). Using your internal users as additional testers is fine, but not to the exclusion of traditional focus groups, useability testing and other requisite methods.



The biggest challenge I continue to face deals with what is now called the Paradox of Choice (which leads to feature creep). Many seem to think in terms of 'more is always better' - when in many(most) cases, streamling or even removing some features is better than adding 'stuff'.



andrew.mcgrath
andrew.mcgrath
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
Points: 3 Visits: 41
So we have built a platform on top of Visual Studio and SQL Server - and the output of that platform (standalone SaaS systems) uses the same generic codebase as the platform tool itself.

And then we have generated our own SaaS solutions for managing aspects of our own business using the platform, so it all gets tested and developed on many fronts simultaneously.

This has been developed over 7 years now.

One of the tools for example is to catalog interesting links we find on the web - so we have a category called SQL Server and SQL Scripts for which most of the content comes from SQLServerCentral :-)
Cheers

Andrew McGrath
workslink.com.au
rf44
rf44
SSC Journeyman
SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)SSC Journeyman (86 reputation)

Group: General Forum Members
Points: 86 Visits: 1088
Things would probably be better is the software vendors big or not so big (this is true for MS too), would care for correcting every known bug in a version of their product before releasing the next version.

As an example, I'm an intensive user of MS Access. With the .NET languages (C# and VB), it's my usual development tool (I don't use it for storing data, just for building front-ends). In Access there are well documented bugs that were already present in the version 2.0 of the product (1993) and that are still there in the 2007 and 2010 versions. Every new release introduces new bugs while no one bothers to fix the existing ones.

And yes, as 90% of the programs we build are for internal use, we have to eat our dog food if it's what we cooked.
Chris Metzger
Chris Metzger
Valued Member
Valued Member (56 reputation)Valued Member (56 reputation)Valued Member (56 reputation)Valued Member (56 reputation)Valued Member (56 reputation)Valued Member (56 reputation)Valued Member (56 reputation)Valued Member (56 reputation)

Group: General Forum Members
Points: 56 Visits: 89
We write several products and don't use any of them for our own purposes (one is a payroll product and my understanding is you shouldn't use your own software in some instances - creates a conflict of interest). But for our flagship product, in the medical records field, we test it as best we can then go through a beta period and deploy it into the field for select clients so they can test usability on a large scale. There's only so much internal testing that can be done but by getting participation from users and clients you can get feedback from the folks that use it most thus put out a product that tries to take into account what the majority of users want (or how they wanteed something to work). As long as we're meeting regulatory requirements everything else is gravy - and that gravy only gets made with help from others (and we'll never please everyone).

Keep it up guys - you'll never please everyone all of the time.
Ernie Schlangen
Ernie Schlangen
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1779 Visits: 449
I work for a medium sized engineering company which only has a couple of applications that are used outside of the company. And both of those were actually developed in-company first and then marketed outside the company so we definitely do eat our own 'dog food'. This is both good and bad, as our internal users are very conversant with the backing theory used by the software but our external users fall into two categories: 1)users that know MUCH more than our average internal user (an 'industry expert') or 2)'casual' users that just want to know enough to use the software for their limited purposes. We get very good feedback from internal users and external 'industry expert' users but the real gold is from the 'casual' users because these users show us where we've assumed knowledge on the part of the user just because that knowledge is common internally. It's important that the feedback from these 'casual' users is not treated lightly by thinking 'oh, that's stupid, everyone knows that'. So, while it's very useful to have the internal use and I firmly believe that companies should use their own products, don't ignore the feedback from the 'real world' either as they tend more to think outside the internal user's 'box'.
Dalkeith
Dalkeith
SSC-Enthusiastic
SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)SSC-Enthusiastic (162 reputation)

Group: General Forum Members
Points: 162 Visits: 1105
I have a few applications now and I dog food some of them and others its not really possible.

I think when specing out a system I'll try if at all possible to have a go at working through some of the work of the clients to get a feel of what they are needing in a try someone else's dog food scenario. I think this is important to do rather than a pure tell me what you want meeting.

Frequently they have no understanding of the table structure of their existing systems and it can be extremely useful to sit over the shoulder of an in house super user and just let them take you through their daily work and let them describe their frustrations and the points they consider good.

But generally I would be a massive fan of dog fooding

I would say that it is a massive advantage to be a developer and user of software. If you really believe your software gives you an advantage in your day to day business then using your own software should be a given.
TravisDBA
TravisDBA
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1462 Visits: 3069
As usual, you are looking at it again from the wrong angle. It should be "Eating your own caviar". I don't know about everyone else but I don't produce "dog food" class software. Do you really know what's in that stuff? It's not what they tell you in the commercials, believe me. :-D

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search