Dog Food

  • Comments posted to this topic are about the item Dog Food

  • Funny you should mention it. My boss and I are discussing roll-outs and the best way to get it done.

    We don't eat our own dog food. We develop software for insurance companies, and wind up having our users test the software for us. The trick is to be sure that the critical parts (the money) is right, which eats a lot of testing time. The balance (usability) is what we hear about most.

    Usability is a tenuous thing. What makes perfect sense to one is "junk" to another.

    You're doing a good job. It works.

  • Steve,

    I have mixed views on the subject. In one sense, I think a company is almost obligated to use its own software if it makes sense for the company. For example, if PeopleSoft is going to market PeopleSoft Financials, it should also be using it. Otherwise, why would an external customer be interested? If PeopleSoft wasn't using its own product, it could indicate that its product is lacking.

    On the other hand, the requirements that go into the software being developed by a company are not always the requirements that actual users of the system would submit. Just because a company is developing an application, doesn't mean it will meet the needs of all communities. Perhaps the application being built is great for one type of organization but not for another. In this instance, I would say that it would be a poor business decision to try to fit the process into the tool. I believe the tool should always support the process, not the other way around.

    ~Cathy

  • My company actually does use its own software internally. One of its offerings is a web-based e-mail and calendar system, and all employees are "strongly encouraged" to use the application and report on any bugs. It's not as good as Microsoft Outlook (yet), but I can say that by having so many employees use the application, is has definitely increased the quality of the product. For my company at least, "dog fooding" the product has been a smart move.

    By the way.... I like the new site. Keep up the good work. 🙂

  • Should software companies "dog food" their own products?

    Interesting question. It made me wonder whether the same questions are asked of other industries - do people who work at car companies drive the cars they make? Do people who work at cereal companies eat that cereal?

    I bet the "eat your own dog food" expectation is higher for software than it is for a lot of other companies. It may be that people are still wary of a company that doesn't use the software it makes. But cars and cereal are so perfected and assembly lined, so to speak, that I bet few people question whether those companies do the same thing.

    But maybe I'm wrong. It's a fascinating issue.

    -------------------
    A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
    Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

  • At the dental company we used our own software. It's strange but follow along. Each practice became an account (family). Each person at the practice who could call us became a "patient". Now the fun starts. Each incident type became a procedure. When someone reported an incident we "charged" them for it. The more severe the incident the higher the "charge". When we resolved and incident we posted a "payment" against the "charge" A partial resolution got a partial "payment".

    Now an ageing report showed which practices had outstanding issues, how bad, and how long. To schedule service work and callbacks we used the appointment scheduler. The productivity report (dollars by procedure) showed the frequency and severity of issue types.

    Our dental practice management software instantly became our software issue tracker. Yep. Use your own stuff when you can. You already paid for it.

    ATBCharles Kincaid

  • Charles,

    That's great and it's a wonderful example of thinking outside the box and looking for reuse. Probably beats buying anything else or tracking bugs in Excel.

  • I guess it would depend if I was importing offshore material to use as filler in my product. Then I definitely would not use my own "dogfood".

    I have always enjoyed trying out new software and finding creative ways to break it from what I perceived as normal user interaction.

    Back in the old days when software came with printed and bound manuals, they were usually written by the same developer/programmer who was deficient in conversational language. In other words, those writers automatically assumed you already understood certain aspects of the program which of course was not true.

    If I could figure out how to make a decent living doing the beta testing, I would do it but it appears to be much cheaper just to throw the product out there and fix it until the next revision comes along and you no longer have to support the old one.

  • I do a lot of internal development for my company, since we are in the entertainment business everybody has something to say regardless they know what is going on or not. Releasing software and applications is the hardest part here and one of the reasons that I have been successful in doing it is that I can ignore the senseless parts and focus on the basics and then fix the miscellaneous stuff. This is hard to swallow for a lot of people as they think that software development is as easy as 1, 2, 3 and a lot of developers don’t know how to get the whole thing done. Now the bad part about it is the comments of people that “it sucks” “can’t you get it right”; you know what is way complicated to make applications these days there is a lot of parts to it and putting it all together is not straight forward as it looks from the outside.

  • Ivan el terrible (9/28/2007)


    I do a lot of internal development for my company, since we are in the entertainment business everybody has something to say regardless they know what is going on or not. ...

    Thank God I'm in industrial stuff then. I go out and look at the job that the users are doing. I map out what data the users have, when they have it, and in what sequence. I then make the software ask for it that way.

    The other stuff around here is sales order entry and direct store delivery. We told our sales folk to put in our products and services into the test database, take a device home and pretend to use it to make sales the way they would when selling software, barcode supplies, and services. They came back and told us exactly what changes we needed to make in order entry. We then had one of our developers go ride in the delivery van. That fixed the delivery end.

    If your users tell you the truth then take that as a guide. If they don't the use YOU best judgement. I've been asked to write software for political campaigns. I won't do it for either party. I just can't trust the client.

    ATBCharles Kincaid

  • 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

  • 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.

  • 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.

  • 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'.

  • 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

Viewing 15 posts - 1 through 15 (of 29 total)

You must be logged in to reply to this topic. Login to reply