-*- mode: outline; coding: utf-8 -*-

* General discussion.

See

  http://en.wikipedia.org/wiki/List_of_software_development_philosophies
  http://en.wikipedia.org/wiki/List_of_eponymous_laws

* Principle of good enough (POGE).

It favours quick-and-simple (but potentially extensible) designs over
elaborate systems designed by committees.

Once the quick-and-simple design is deployed, it can then evolve as needed,
driven by user requirements.

This kind of design is not appropriate in systems where it is not possible to
evolve the system over time, or where the full functionality is required from
the start.

See

  http://en.wikipedia.org/wiki/Principle_of_good_enough

* No Silver Bullet.

There is no single development, in either technology or management technique,
which by itself promises even one order of magnitude improvement within a
decade in productivity, in reliability, in simplicity.

See

  http://en.wikipedia.org/wiki/No_Silver_Bullet

* Rule of thumb.

A rule of thumb is a principle that postulate in some case use simple
procedure wich produce approximate result instead use complex but exact
produce.

See

  http://en.wikipedia.org/wiki/Rule_of_thumb

* The Zero One or Infinity.

The Zero One or Infinity (ZOI) rule is a rule of thumb in software design. It
suggests that arbitrary limits on the number of instances of a particular
entity should not be allowed. Specifically, that an entity should either be
forbidden entirely, one should be allowed, or any number (presumably, to the
limit of available storage) of them should be allowed. It should not be the
software that puts a hard limit on the number of instances of the entity.

  http://en.wikipedia.org/wiki/Zero_One_Infinity

* 80-20 rule (pareto principle).

This rule postulate that roughly 80% of the effects come from 20% of the
causes.

This rule applied to optimisation (most time spent by program only by little
piece of code), functionality (80% of users use only 20% of program
functionality); bugs (fixing the top 20% of most reported bugs solve 80% of
the error and crashes).

See

  http://en.wikipedia.org/wiki/80:20_rule

* 1% rule.

The 1% rule states that the number of people who create content on the
internet represents approximately 1% (or less) of the people actually viewing
that content.

See

  http://en.wikipedia.org/wiki/1%25_rule_%28Internet_culture%29

* Parkinson's Law.

Work expands so as to fill the time available for its completion.

Data expands to fill the space available for storage.

See

  http://en.wikipedia.org/wiki/Parkinson%27s_law

* Ninety-ninety rule.

The first 90% of the code accounts for the first 10% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.

See

  http://en.wikipedia.org/wiki/Ninety-ninety_rule

* Wirth's law.

Software is getting slower more rapidly than hardware becomes faster.

See

  http://en.wikipedia.org/wiki/Wirth%27s_law

* Student syndrome.

Student syndrome refers to the phenomenon that many people will start to fully
apply themselves to a task just at the last possible moment before a deadline.

The student syndrome is a form of procrastination ().

See

  http://en.wikipedia.org/wiki/Student_syndrome

* Conway's Law.

...organizations which design systems ... are constrained to produce designs
which are copies of the communication structures of these organizations.

Example: Consider a two-person team of software engineers, A and B. Say A
designs and codes a software class X. Later, the team discovers that class X
needs some new features. If A adds the features, A is likely to simply expand
X to include the new features. If B adds the new features, B may be afraid of
breaking X, and so instead will create a new derived class X2 that inherits
X's features, and puts the new features in X2. So the final design is a
reflection of who implemented the functionality.

A real life example: NASA's Mars Climate Orbiter crashed because one team used
United States customary units (e.g., inches, feet and pounds) while the other
used metric units for a key spacecraft operation.

See

  http://en.wikipedia.org/wiki/Conway%27s_Law

* Brooks's law.

It takes some time for the people added to a project to become productive.

Communication overheads increase as the number of people increases.

Adding manpower to a late software project makes it later.

See

  http://en.wikipedia.org/wiki/Brooks%27_law

* Code bloat.

Code bloat is the production of code that is perceived as unnecessarily long,
slow, or otherwise wasteful of resources. Code bloat generally refers to
source code size but sometimes is used to refer to the generated code size or
even the binary file size.

  http://en.wikipedia.org/wiki/Code_bloat

* Beerware.

Beerware is term for software released under a very relaxed license. It
provides the end user with the right to use a particular program.

Should the user of the product meet the author and consider the software
useful, he is encouraged to buy the author a beer 'in return' (or, in some
variations, drink a beer in the author's honor).

/* ----------------------------------------------------------------------------
 * "THE BEER-WARE LICENSE" (Revision 42):
 * <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you
 * can do whatever you want with this stuff. If we meet some day, and you think
 * this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp
 * ----------------------------------------------------------------------------
 */

  http://en.wikipedia.org/wiki/Beerware

* Demoware.

Demoware (also known as trialware) is commercial software released for free
(shareware) in a version which is limited in one or more ways.

  http://en.wikipedia.org/wiki/Demoware

* Crippleware.

Crippleware is any product whose functions have been limited (or "crippled")
with the sole purpose of encouraging or requiring the user to pay for those
functions (either by paying a one-time fee or an on-going subscription fee).
Crippleware is also a term used to describe software that makes use of Digital
Rights Management.

  http://en.wikipedia.org/wiki/Crippleware

* Nagware.

Nagware (also known as begware, annoyware or a nagscreen) is a type of
shareware that reminds (or nags) the user to register it by paying a fee. It
usually does this by popping up a message when the user starts the program, or
intermittently while the user is using the application. These messages can
appear as windows obscuring part of the screen or message boxes that can
quickly be closed. Some nagware keeps the message up for a certain time
period, forcing the user to wait to continue to use the program.

  http://en.wikipedia.org/wiki/Nagware

* Registerware.

Registerware refers to computer software which requires the user to give
personal information, e.g an email address, through registration in order to
download or use the program.

  http://en.wikipedia.org/wiki/Registerware

* Scareware.

Scareware comprises several classes of scam software, often with limited or no
benefit, sold to consumers via certain unethical marketing practices.

  http://en.wikipedia.org/wiki/Scareware

* Donationware.

Donationware is a licensing model that supplies fully operational software to
the user and pleads for an optional donation be paid to the programmer or a
third-party beneficiary (usually a non-profit). The amount of the donation may
also be stipulated by the author, or it may be left to the discretion of the
user, based on individual perceptions of the software's value. Since
donationware comes fully operational (i.e. not crippleware) and payment is
optional, it is a type of freeware.

  http://en.wikipedia.org/wiki/Donationware

* Freeware.

Freeware is computer software that is available for use at no cost or for an
optional fee.

  http://en.wikipedia.org/wiki/Freeware

* Shareware.

Shareware is proprietary software that is provided to users without payment on
a trial basis and is often limited by any combination of functionality,
availability or convenience. Shareware is often offered as a download from an
Internet website or as a compact disc included with a magazine.

The rationale behind shareware is to give buyers the opportunity to use the
program and judge its usefulness before purchasing a license for the full
version of the software.

The words "free trial" or "trial version" are indicative of shareware.

  http://en.wikipedia.org/wiki/Shareware

* Software bloat.

Software bloat is a term used to describe the tendency of newer computer
programs to have a larger installation footprint, or have many unnecessary
features that are not used by end users, or just generally use more system
resources than necessary, while offering little or no benefit to its users.


Comparison of Microsoft Windows minimum hardware requirements (for 32-bit
versions):

Windows version     Processor   Memory  Hard disk
Windows 95[4]        25 MHz      4 MB    ~50 MB
Windows 98[5]        66 MHz     16 MB   ~200 MB
Windows 2000[6]     133 MHz     32 MB    650 MB
Windows XP[7]       233 MHz     64 MB    1.5 GB
Windows Vista[8]    800 MHz    512 MB     15 GB
Windows 7[9]          1 GHz      1 GB     16 GB

Every program attempts to expand until it can read mail. Those programs which
cannot so expand are replaced by ones which can.
                                                   -- Jamie Zawinski

** Foistware.

Foistware, Bloatware, or Bundler is software bundled with completely unrelated
programs. That means that there is no particular property in the software that
makes it foistware, but rather the context in which it was installed.

  http://en.wikipedia.org/wiki/Foistware

** Bloatware.

Software bloat is a term used to describe the tendency of newer computer
programs to have a larger installation footprint, or have many unnecessary
features that are not used by end users, or just generally use more system
resources than necessary, while offering little or no benefit to its users.
Bloatware, or foistware, is also used to describe software that comes
pre-installed on a computer when it's bought, mostly consisting of
time-limited trials or feature-lacking basic or "beginner" versions.

  http://en.wikipedia.org/wiki/Bloatware

** Shovelware.

Shovelware is sometimes used to denote foistware which was chosen to fill up
the remaining space on a freely distributed CD-ROM.

  http://en.wikipedia.org/wiki/Shovelware

* Second-system effect.

In computing, the second-system effect or sometimes the second-system syndrome
refers to the tendency, when following on from a relatively small, elegant,
and successful system, to design the successor as an elephantine,
feature-laden monstrosity. The term was first used by Fred Brooks in his
classic The Mythical Man-Month.[1] It described the jump from a set of simple
operating systems on the IBM 700/7000 series to OS/360 on the 360 series.

* Inner-platform effect.

The inner-platform effect is the tendency of software architects to create a
system so customizable as to become a replica, and often a poor replica, of
the software development platform they are using.

XXX read more http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx

  http://en.wikipedia.org/wiki/Inner-platform_effect

* Feature creep.

Feature creep is the proliferation of features in a product such as computer
software. Extra features go beyond the basic function of the product and so
can result in baroque over-complication, or "featuritis", rather than simple,
elegant design.

  http://en.wikipedia.org/wiki/Feature_creep

* Bullet-point engineering.

Bullet-point engineering is a software design anti-pattern where developers
use the features of competing software packages as checklists of features to
implement in their own product. These features are often implemented poorly
and haphazardly, without any real design, merely so they can be added to a
bulleted list of features in marketing material. Bullet point engineering
often leads to feature creep and software bloat but may also simply result in
a poorly designed imitative product.

  http://en.wikipedia.org/wiki/Bullet-point_engineering

* KISS

Keep it simple and stupid, or keep it simple, stupid!

Instruction creep and function creep, two instances of creeping featuritis,
are examples of failure to follow the KISS principle in software development.

  http://en.wikipedia.org/wiki/KISS_principle

* Minimalism.

In computing, minimalism refers to the application of minimalist philosophies
and principles in hardware and software design and usage.

  http://en.wikipedia.org/wiki/Minimalism_%28computing%29

* Unix philosophy.

** From Doug McIlroy.

"Do one thing and do it well."

"Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a universal
interface."

** From Pike: Notes on Programming in C.

 1. You cannot tell where a program is going to spend its time. Bottlenecks
occur in surprising places, so do not try to second guess and put in a speed
hack until you've proven that's where the bottleneck is.
 2. Measure. Do not tune for speed until your performance analysis tool tells
you which part of the code overwhelms the rest.
 3. Fancy algorithms tend to run more slowly on small data sets than simple
algorithms. They tend to have a large constant factor in O(n) analysis, and n
is usually small. So don't get fancy unless Rule 2 indicates that n is big
enough.
 4. Simplify your algorithms and data structures wherever it makes sense
because fancy algorithms are more difficult to implement without defects. The
data structures in most programs can be built from array lists, linked lists,
hash tables, and binary trees.
 5. Data dominates. If you have chosen the right data structures and organized
things well, the algorithms will almost always be self-evident. Data
structures, not algorithms, are central to programming.

** From Mike Gancarz: The UNIX Philosophy.

 1. Small is beautiful.
 2. Make each program do one thing well.
 3. Build a prototype as soon as possible.
 4. Choose portability over efficiency.
 5. Store data in flat text files.
 6. Use software leverage to your advantage.
 7. Use shell scripts to increase leverage and portability.
 8. Avoid captive user interfaces.
 9. Make every program a filter.

With this not all agree:

 1. Allow the user to tailor the environment.
 2. Make operating system kernels small and lightweight.
 3. Use lowercase and keep it short.
 4. Save trees.
 5. Silence is golden.
 6. Think parallel.
 7. The sum of the parts is greater than the whole.
 8. Look for the 90-percent solution.
 9. Worse is better.
 10. Think hierarchically.

** Misc.

"Unix is simple. It just takes a genius to understand its simplicity."
                              -– Dennis Ritchie
"Unix never says 'please'."
                              -– Rob Pike

  http://en.wikipedia.org/wiki/Unix_philosophy

* Worse is better.

In the "Worse is better" design style, simplicity of both the interface and
the implementation is more important than any other attribute of the system —
including correctness, consistency and completeness.

Simplicity
  The design must be simple, both in implementation and interface. It is
  more important for the implementation to be simpler than the interface.
  Simplicity is the most important consideration in a design.
Correctness
  The design must be correct in all observable aspects. It is slightly better
  to be simple than correct.
Consistency
  The design must not be overly inconsistent. Consistency can be sacrificed
  for simplicity in some cases, but it is better to drop those parts of the
  design that deal with less common circumstances than to introduce either
  implementational complexity or inconsistency.
Completeness
  The design must cover as many important situations as is practical. All
  reasonably expected cases should be covered. Completeness can be sacrificed
  in favor of any other quality. In fact, completeness must be sacrificed
  whenever implementation simplicity is jeopardized. Consistency can be
  sacrificed to achieve completeness if simplicity is retained; especially
  worthless is consistency of interface.

  http://dreamsongs.com/WIB.html
                Lisp: Good News, Bad News, How to Win Big

* The right thing.

The MIT approach (known as "The right thing"):

Simplicity
  The design must be simple, both in implementation and interface. It is
  more important for the interface to be simpler than the implementation.
Correctness
  The design must be correct in all observable aspects. Incorrectness is
  simply not allowed.
Consistency
  The design must be consistent. A design is allowed to be slightly less
  simple and less complete to avoid inconsistency. Consistency is as important
  as correctness.
Completeness
  The design must cover as many important situations as is practical. All
  reasonably expected cases must be covered. Simplicity is not allowed to
  overly reduce completeness.

  http://dreamsongs.com/WIB.html
                Lisp: Good News, Bad News, How to Win Big

* YAGNI.

"You aren't gonna need it" (or YAGNI for short) is the principle in extreme
programming that programmers should not add functionality until it is
necessary.

  http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it

* DRY (DIE).

Don't Repeat Yourself (DRY) or Duplication is Evil (DIE).

 * VCS allow multiple and diverging copies ("branches").
 * Source code generation.

  http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

* Do it yourself (DIY).

Do it yourself (or DIY) is a term used to describe building, modifying, or
repairing of something without the aid of experts or professionals.

when tasklist longer then people life mutch easy use already written libraries
then wrote own.

  http://en.wikipedia.org/wiki/Do_it_yourself

* Once and Only Once (OAOO).



* MoSCoW Method.

The capital letters in MoSCoW stand for:

 * M - MUST have this (included in the current delivery timebox in order
   for it to be a success).
 * S - SHOULD have this if at all possible (critical to the success of the
   project, but are not necessary for delivery in the current delivery
   timebox).
 * C - COULD have this if it does not affect anything else (nice to have).
 * W - WON'T have this time but WOULD like in the future.

  http://en.wikipedia.org/wiki/MoSCoW_Method

* Abandonware.

Abandonware is a term used to describe computer software that is no longer
sold or supported, or whose copyright ownership may be unclear for various
reasons. While the term has been applied largely to older games, utility
software, etc.

  http://en.wikipedia.org/wiki/Abandonware

* Separation of concerns.

In computer science, separation of concerns (SoC) is the process of separating
a computer program into distinct features that overlap in functionality as
little as possible. A concern is any piece of interest or focus in a program.
Typically, concerns are synonymous with features or behaviors. Progress
towards SoC is traditionally achieved through modularity of programming and
encapsulation (or "transparency" of operation), with the help of information
hiding. Layered designs in information systems are also often based on
separation of concerns (e.g., presentation layer, business logic layer, data
access layer, database layer).

HyperText Markup Language (HTML) and cascading style sheets (CSS) are
languages intended to separate style from content.

  http://en.wikipedia.org/wiki/Separation_of_concerns

* Modular design.

In systems engineering, modular design — or "modularity in design" — is an
approach that subdivides a system into smaller parts (modules) that can be
independently created and then used in different systems to drive multiple
functionalities.

  http://en.wikipedia.org/wiki/Modular_design

* Occam's razor.

"entia non sunt multiplicanda praeter necessitatem"

Entities must not be multiplied beyond necessity.

* Code and fix.

Programmers immediately begin producing code. Bugs must be fixed before the
product can be shipped.

  http://en.wikipedia.org/wiki/Code_and_fix

* Cowboy coding.

Cowboy coding is a term used to describe software development where the
developers have autonomy over the development process. This includes control
of the project's schedule, algorithms, tools, and coding style.

A cowboy coder can be a lone developer or part of a group of developers with
either no external management or management that controls only non-development
aspects of the project, such as its nature, scope, and feature set (the
"what", but not the "how").

  http://en.wikipedia.org/wiki/Cowboy_coding

* Extreme Programming.

  http://en.wikipedia.org/wiki/Extreme_Programming

* Hollywood Principle.

In computer programming, the Hollywood Principle is stated as "don't call us,
we'll call you." It has applications in software engineering; see also
implicit invocation for a related architectural principle.

  http://en.wikipedia.org/wiki/Hollywood_Principle

* Inversion of control.

Inversion of control, or IoC, is an abstract principle describing an aspect of
some software architecture designs in which the flow of control of a system is
inverted in comparison to procedural programming.

  http://en.wikipedia.org/wiki/Inversion_of_control

* Literate programming.

  http://en.wikipedia.org/wiki/Literate_Programming

* Model-driven architecture.

  http://en.wikipedia.org/wiki/Model-driven_architecture

* Quick-and-dirty.

Quick-and-dirty is a term used in reference to anything that is an easy way to
implement a workaround or "kludge." Its usage is popular among programmers,
who use it to describe a crude solution or programming implementation that is
imperfect, inelegant, or otherwise inadequate, but which solves or masks the
problem at hand, and is generally faster and easier to put in place than a
proper solution.

  http://en.wikipedia.org/wiki/Quick-and-dirty

* Release early, release often.

Release early, release often (sometimes abbreviated RERO) is a software
development philosophy that emphasizes the importance of early and frequent
releases in creating a tight feedback loop between developers and testers or
users.

  http://en.wikipedia.org/wiki/Release_early,_release_often

* Test-driven development.

Test-driven development (TDD) is a software development technique that relies
on the repetition of a very short development cycle: First the developer
writes a failing automated test case that defines a desired improvement or new
function, then produces code to pass that test and finally refactors the new
code to acceptable standards.

  http://en.wikipedia.org/wiki/Test-driven_development

* Unified Process.

The Unified Software Development Process or Unified Process is a popular
iterative and incremental software development process framework. The
best-known and extensively documented refinement of the Unified Process is the
Rational Unified Process (RUP).

  http://en.wikipedia.org/wiki/Unified_Process

* Waterfall model.

   1. Requirements specification
   2. Design
   3. Construction (AKA implementation or coding)
   4. Integration
   5. Testing and debugging (AKA Validation)
   6. Installation
   7. Maintenance

  http://en.wikipedia.org/wiki/Waterfall_model

* Do it yourself.