tips: comparison devel-rules.rst

equal deleted inserted replaced

-:da0024f4f068
+:2e3bc2435d68
--*- 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.

changeset 1894	2e3bc2435d68
parent 1893	da0024f4f068
child 1895	91e537a35a34