+
−.. -*- coding: utf-8; -*-
+
−
+
−============================
+
− Software development rules
+
−============================
+
−.. contents::
+
−   :local:
+
−
+
−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
+
−
+
−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
+
−
+
−.. epigraph::
+
−
+
−  Every program attempts to expand until it can read mail. Those programs which
+
−  cannot so expand are replaced by ones which can.
+
−
+
−  -- Jamie Zawinski
+
−
+
−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
+
−===============
+
−
+
−.. epigraph::
+
−
+
−  "Do one thing and do it well."
+
−
+
−  -- Doug McIlroy
+
−
+
−.. epigraph::
+
−
+
−   "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."
+
−
+
−  -- Doug McIlroy
+
−
+
−.. epigraph::
+
−
+
−   #. 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.
+
−   #. Measure. Do not tune for speed until your performance analysis tool tells
+
−      you which part of the code overwhelms the rest.
+
−   #. 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.
+
−   #. 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.
+
−   #. 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.
+
−
+
−   -- Pike: Notes on Programming in C.
+
−
+
−.. epigraph::
+
−
+
−   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.
+
−
+
−   -- Mike Gancarz: The UNIX Philosophy
+
−
+
−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
+
−
+
−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.