Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

Dog Food Expand / Collapse
Author
Message
Posted Friday, September 28, 2007 11:46 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Friday, November 21, 2014 6:34 AM
Points: 6,259, Visits: 2,031
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
Post #404181
Posted Friday, September 28, 2007 12:09 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, April 10, 2009 10:42 AM
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.
Post #404190
Posted Friday, September 28, 2007 1:06 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, April 9, 2008 9:05 AM
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.
Post #404216
Posted Friday, September 28, 2007 1:30 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, October 31, 2014 5:16 AM
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'.





Post #404223
Posted Wednesday, October 3, 2012 4:19 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, March 9, 2014 10:31 PM
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
Post #1367534
Posted Wednesday, October 3, 2012 5:04 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Yesterday @ 5:18 AM
Points: 84, Visits: 1,041
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.

Post #1367558
Posted Wednesday, October 3, 2012 5:29 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, February 11, 2013 8:23 AM
Points: 50, Visits: 88
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.
Post #1367576
Posted Wednesday, October 3, 2012 5:54 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 8:22 AM
Points: 1,623, Visits: 359
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'.
Post #1367590
Posted Wednesday, October 3, 2012 7:41 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, November 19, 2014 11:03 AM
Points: 108, Visits: 814
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.
Post #1367678
Posted Wednesday, October 3, 2012 8:11 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
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.

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1367704
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse