[ About | Licence | Contacts ]
Written by Oleksandr Gavenko (AKA gavenkoa), compiled on 2017-01-30 from rev ccaa2f364422+.

Software development rules

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

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

"Do one thing and do it well."

—Doug McIlroy

"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

  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.

—Pike: Notes on Programming in C.

  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