Showing posts with label software and games. Show all posts
Showing posts with label software and games. Show all posts

Friday, May 17, 2013

ATIT Reheated: Eat your own dog food!

By Jack Brummet, Games and Software Ed.


Actor Lorne Greene used to flack the dogfood Alpo on TV, saying "it's so good I feed it to my own dogs." It gained currency during the dot-com craze, and the phrase is still used most commonly in technology companies. I believe it is one of the central tenets of quality assurance (as opposed to QA's subdiscipline, testing).


"Eating your own dog food" means that you use the software you create, or play the games you make. In other businesses, you might actually eat the food you serve, watch the TV shows you make, or use the product you manufacture. This can be taken to extremes, of course, as in the Not Invented Here syndrome, where you not only eat your own dogfood, but you also won't touch anyone else's [1].




Ben Hamper, writing about life as a shoprat at General Motors in his book Rivethead, tells how anyone foolish enough to drive a foreign car into the employee parking lot would find their car keyed, tagged with spray paint, mirrors ripped off, and possibly rammed by a one-ton pickup. That is an extreme punishment for not eating your own dogfood.

Why should you eat your own dogfood? You actually get to know the product you are making. By knowing it, you may get some ideas about how to increase its goodness. In the case of games and software, problems, bugs and deficencies become apparent often only after extended use by a variety of people. Eating your own dogfood shows you believe in your own product. If you work at a brewery, a game company, or bakery, it probably works pretty well for you, if you manufacture cod liver oil, syrup of ipecac, chastity belts, or experimental aircraft. . .well, not so much.

[1] "Not Invented Here," describes a company that will use nothing developed by "outsiders." In many cases companies don't know a solution already exists. But even more often, the organization believes they can produce a superior product. Apple Computer, from System 1 through OS9 did not include many U.I. innovations (from, say, Windows) because they were not accounted for in Apple's human interface guidelines (a great document, by the way).


Apple rejected any change they did not invent...which, of course, ignores the fact that Apple cribbed most of this stuff from innovations at PARC (Palo Alto Research Center) in the first place. In the open source world, at any time, there are several groups working on different projects that all do the same thing.


Large corporations like Microsoft reject all use of open source software...because they feel the source sharing requirements are too onerous. Therefore they must come up with all these tools in house, no matter how much it costs and no matter how poorly the tool emulates what is already available for free.
---o0o---

Wednesday, June 09, 2010

Eat your own dog food!

By Jack Brummet, Games and Software Ed.


Actor Lorne Greene used to flack the dogfood Alpo on TV, saying "it's so good I feed it to my own dogs." It gained currency during the dot-com craze, and the phrase is still used most commonly in technology companies. I believe it is one of the central tenets of quality assurance (as opposed to QA's subdiscipline, testing).


"Eating your own dog food" means that you use the software you create, or play the games you make. In other businesses, you might actually eat the food you serve, watch the TV shows you make, or use the product you manufacture. This can be taken to extremes, of course, as in the Not Invented Here syndrome, where you not only eat your own dogfood, but you also won't touch anyone else's [1].




Ben Hamper, writing about life as a shoprat at General Motors in his book Rivethead, tells how anyone foolish enough to drive a foreign car into the employee parking lot would find their car keyed, tagged with spray paint, mirrors ripped off, and possibly rammed by a one-ton pickup. That is an extreme punishment for not eating your own dogfood.

Why should you eat your own dogfood? You actually get to know the product you are making. By knowing it, you may get some ideas about how to increase its goodness. In the case of games and software, problems, bugs and deficencies become apparent often only after extended use by a variety of people. Eating your own dogfood shows you believe in your own product. If you work at a brewery, a game company, or bakery, it probably works pretty well for you, if you manufacture cod liver oil, syrup of ipecac, chastity belts, or experimental aircraft. . .well, not so much.

[1] "Not Invented Here," describes a company that will use nothing developed by "outsiders." In many cases companies don't know a solution already exists. But even more often, the organization believes they can produce a superior product. Apple Computer, from System 1 through OS9 did not include many U.I. innovations (from, say, Windows) because they were not accounted for in Apple's human interface guidelines (a great document, by the way).


Apple rejected any change they did not invent...which, of course, ignores the fact that Apple cribbed most of this stuff from innovations at PARC (Palo Alto Research Center) in the first place. In the open source world, at any time, there are several groups working on different projects that all do the same thing.


Large corporations like Microsoft reject all use of open source software...because they feel the source sharing requirements are too onerous. Therefore they must come up with all these tools in house, no matter how much it costs and no matter how poorly the tool emulates what is already available for free.
---o0o---

Wednesday, March 23, 2005

Old School Corporate Software Scam



After my office recently received the third new release of some business software in a couple of weeks, I remembered how it went at **** ****. 

In the mid-90s, I worked at a large and now defunct software company that made software named after well-known Latin dances.

Right before a new product hit the shelves or any customers had seen it, the first PTF (programmatic temporary fix) patches would be posted. We fixed the bugs we missed or didn't have time to tackle before we "went gold." First we fixed "known failures," bugs we knew about, and shipped with anyway. We ranked that list according to how users would howl when they were victims of the unexpected behavior. Fortune 500 firm's failures were escalated even further up the priority list).

At **** ****, we never called software errors bugs. They were failures. This was to remind us that we had failed our customer. Mostly, we failed the customer in order to book revenue for the quarter

Once the software was deployed "in the field," the bugs really started rolling in. We created new patches every day. These were collected every week into a cumulative PTF. Once a month, cumulative PTFs were collected into a "TMP" release, and once a quarter, all the TMPs were released as an "update."

The best part was that we received something like $250 per year per seat (many hundreds of thousands of dollars for some companies) to fix all the bugs we put in in the first place.

After a year or so, we tossed all the fixes in with some new features and then charged for an "upgrade." Is this a great country, or what? /jack
---o0o---