Collection of software engineering concepts, principles, laws, practices, patterns and properties worth having present in the software engineer's practice.
Loss of potential gain from other alternatives when one particular alternative is chosen over the others. (from Wikipedia)
The simplest explanation is usually the right one. When presented with different solutions to the same problem, one should select the one with the fewest assumptions. (from Wikipedia)
Overthinking a situation can cause forward motion to become "paralyzed". (from Wikipedia)
Difficulty in understanding an issue and effectively making decisions when one has too much information about that issue. (from Wikipedia)
Searching through the available alternatives until an acceptability threshold is met. (from Wikipedia)
80% of consequences come from 20% of the causes (the “vital few”). (from Wikipedia)
You aren't gonna need it. Always implement things when you actually need them, never when you just foresee that you need them. (from Wikipedia)
Software quality does not necessarily increase with functionality. There is a point where less functionality is the preferable option. (from Wikipedia)
Minimum Viable Product. Version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. (from Wikipedia)
Minimum Marketable Features. ROI-informed approach to software development in which software is developed and delivered in carefully prioritized chunks of customer valued functionality. (from Wikipedia)
Achieving absolute perfection may be impossible and so, as increasing effort results in diminishing returns, further activity becomes increasingly inefficient. (from Wikipedia)
Keep it simple, stupid. Most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided. (from Wikipedia)
Don't repeat yourself. Reduce repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy. (from Wikipedia)
Be conservative in what you do, be liberal in what you accept from others. (from Wikipedia)
Immediately report any condition that is likely to indicate a failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process. (from Wikipedia)
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. (from Wikipedia)
Every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction. (from Wikipedia)
Applies to user interface and software design. It proposes that a component of a system should behave in a way that most users will expect it to behave. The behavior should not astonish or surprise users. The following is a formal statement of the principle: "If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature." (from Wikipedia)
Animals, people, and even well-designed machines will naturally choose the path of least resistance or "effort". (from Wikipedia)
In information security, computer science, and other fields, the principle of least privilege (PoLP), requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose. (from Wikipedia)
Design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling that can be succinctly summarized in each of the following ways:
- Each unit should only have limited knowledge about other units "closely" related.
- Each unit should only talk to its friends; don't talk to strangers.
- Only talk to your immediate friends.
The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents), in accordance with the principle of "information hiding". (from Wikipedia)
Choosing the least powerful alternative suitable for a given purpose. (from Wikipedia)
####### Anticipation of change ####### Build to change over build to last
####### Dependencies ######## Minimize them ######## Make them explicit ######## Minimize probability of cascading failures
- Mechanical Sympathy (Martin Thompson)
- Latency numbers every programmer should know (Jonas Bonér)
Formula which gives the theoretical speedup in latency of the execution of a task at fixed workload that can be expected of a system whose resources are improved. (from Wikipedia)
- Introduction (Henry Robinson)
- Distributed systems course, lecture, notes (Dr. Martin Kleppmann)
- Towards robust distributed systems (Dr. Eric A. Brewer)
- Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services (Seth Gilbert & Nancy Lynch)
- The CAP FAQ (Henry Robinson)
- A critique of the CAP theorem (Dr. Martin Kleppmann)
Test desired properties as described in TestDesiderata (Kent Beck).
- Automated
- Specific: One reason to fail
- Deterministic
- Isolation
- Composition
- Provides confidence
- Fast execution
- Writeable: Cheap
- Readable: Descriptive
- Behavioral: Sensitive to behavior change
- Structure insensitive
- Predictive
- Eisenhower's matrix (Dwight D. Eisenhower)
Work expands so as to fill the time available for its completion. (from Wikipedia)
People within an organization commonly or typically give disproportionate weight to trivial issues. (from Wikipedia)
Bottom line up front. Paragraph where the conclusions and recommendations are placed at the beginning of the text, rather than the end, in order to facilitate rapid decision making. (from Wikipedia)