Banana principle

from Wikipedia, the free encyclopedia

The banana principle is a sarcastic expression for the idea that a still immature (read: defective) product can mature at the consumer . The basis is the fact that bananas are harvested unripe, delivered green and only after a ripening period they can be consumed by the intermediary or even by the end consumer.

A positive effect for a commercial enterprise is that internal testing and quality assurance measures can be partially saved. The defects of the product are determined through the customer feedback and complaints. The manufacturers therefore also refer to the process as "customization". Ultimately, however, the customer finances the finished development of the restricted product through his purchase.

The term is primarily used in industries that deal with software or automobiles. A core property of software is that it can be changed after delivery to the customer at potentially very low costs for the provider. In particular, the costs can be largely independent of the number of products to be delivered, for example when updates are made via the Internet. This is naturally different in the case of physical changes, including, for example, recalls from car manufacturers.

As a result, quick and relatively more cost-effective adjustments are possible in all product groups, which are essentially controlled by easily updatable software - including hardware components in computers and other technical components.

The cheap replicability of software stands in contrast to the high costs of software development, in particular also to a high proportion of costs for quality assurance and tests. Because of this, there is great interest on the part of the manufacturers in reducing the costs of this phase.

Banana ware

Of bananas goods , bananas software or banana ware one speaks mostly when it came on the customer side to a related dissatisfaction, that is, the software or an update has been the program or the Internet before passing to the purchaser or user is not sufficiently tested. The programs are made available immediately, without sufficient troubleshooting in beta tests - or even without ever having performed an alpha test. The manufacturers concerned often point out that it is impossible to test all end-user configurations for possible errors. Resolving the problem by updating it according to problem descriptions is therefore not only more cost-effective, but also the only realistic option.

The users can often not or only partially use the software or service that has already been paid for. After complaining to the manufacturer, you have to wait for the update, sometimes pay extra for it, and enter data again with an improved program. In addition, products that can be expanded by the customer may have to be adapted to the updated version.

This principle also often occurs in computer games. Patches are needed before the game runs satisfactorily. The trend is also establishing itself in console games, as consoles are now connected to the Internet and patches can be delivered subsequently. Previously, critical software errors required the game medium to be sent in and replaced, which could be correspondingly expensive for the manufacturer.

However , the role of the (end) user has changed due to the Internet and the development of open source programs. He often does not receive a finished product, but a service that can be accessed via the network. Appropriate adjustments to the programs and regular updates ( updates ) are often included. With some program developers, the terms Continuous Beta or Perpetual Beta (both freely translated in English / Latin / Greek, for example for permanent advance version or colloquially constant banana products ) have become commonplace. The user should be seen as a co-developer in the process of further developing a program.

Web links

Individual evidence

  1. ↑ Martin Sonnenschein, Harald Zapp, Axel Freyberg: Customer Energy: How companies learn to use the power of the customer for themselves. Gabler, 2006, ISBN 978-3-409-14264-9 , p. 120.
  2. ↑ Henning Wallentowitz, Arndt Freialdenhoven, Ingo Olschewski: Strategies in the automotive industry: technology trends and market developments. Vieweg & Teubner, 2008, ISBN 978-3-8348-0725-0 , p. 9.
  3. ↑ Recalls record: car development based on the banana principle. Spiegel Online Auto, December 15, 2003 (accessed April 29, 2011).
  4. ↑ Thomas Hirschbiegl: Temporary rigor mortis . In: Berliner Zeitung , March 31, 1999.
  5. ↑ Thomas Hirschbiegl: The banana principle . In: Berliner Zeitung , June 20, 2001.
  6. ↑ Frank Mühlenbeck, Klemens Skibick: Social Commerce Sales Channel - Blogs, Podcasts, Communities & Co. How to make money with Web 2.0 Marketing. 2007, ISBN 3-8334-9686-X , p. 20.
  7. ↑ Tim O'Reilly: What is Web 2.0? Chapter 4/2: End of the Software Release Cycle .