Software Engineering Principles

Collection of software engineering concepts, principles, laws, practices, patterns and properties worth having present in the software engineer's practice.

Mind Map

Basics

Don't reinvent the wheel

Measure and monitor

SOLID

Single responsibility

Open-closed

Liskov substitution

Interface segregation

Dependency inversion

Economics

Opportunity cost

Loss of potential gain from other alternatives when one particular alternative is chosen over the others. (from Wikipedia)

Last responsible moment

Proof of concepts

Bring the pain forward

Problem solving & Decision making

Occam's razor

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)

Analysis paralysis

Overthinking a situation can cause forward motion to become "paralyzed". (from Wikipedia)

Information overload

Difficulty in understanding an issue and effectively making decisions when one has too much information about that issue. (from Wikipedia)

Satisficing

Searching through the available alternatives until an acceptability threshold is met. (from Wikipedia)

Pareto principle (80:20)

80% of consequences come from 20% of the causes (the “vital few”). (from Wikipedia)

Strategies

Top-down

Bottom-up

Divide and conquer

Visualize the goal

Build iteratively

Feedback loops

Shift left

Crawl, walk, run

Work, right, pretty

Simple, Correct, Consistent, Complete

Features

YAGNI ~ When in doubt, leave it out

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)

Worse is better ~ Less is more

Software quality does not necessarily increase with functionality. There is a point where less functionality is the preferable option. (from Wikipedia)

ROI

MVP

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)

MMF

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)

Perfect is the enemy of good ~ Golden mean

Achieving absolute perfection may be impossible and so, as increasing effort results in diminishing returns, further activity becomes increasingly inefficient. (from Wikipedia)

System design

KISS

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)

DRY

Don't repeat yourself. Reduce repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy. (from Wikipedia)

Robustness ~ Postel's law

Be conservative in what you do, be liberal in what you accept from others. (from Wikipedia)

Fail fast

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)

Gall's law

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)

Conservation of complexity ~ Tesler's law

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)

Least

Least Astonishment

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)

Least Effort

Animals, people, and even well-designed machines will naturally choose the path of least resistance or "effort". (from Wikipedia)

Least Privilege

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)

Least Knowledge: Law of Demeter

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)

Least Power

Choosing the least powerful alternative suitable for a given purpose. (from Wikipedia)

Separation of concerns

Bounded contexts

Abstraction

Generality

Don't mix different levels of abstraction

Modularity

Functional independence

Cohesiveness

####### Anticipation of change ####### Build to change over build to last

Coupling

####### Dependencies ######## Minimize them ######## Make them explicit ######## Minimize probability of cascading failures

Information hiding

Encapsulation

API

Hyrum's Law

Programming

Functional

Pure functions

Immutability

Shallow vs deep copies

Referential transparency

No side effects

Composition

Partial application

Currying

Higher order functions

Composition over inheritance

Boy-scout rule

Conventions

Methods

Named after what they do with a verb

Do only one thing

Data comes last in signature

Performance

Mechanical Sympathy

Mechanical Sympathy (Martin Thompson)

Latency numbers

Latency numbers every programmer should know (Jonas Bonér)

Amdahl's Law

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)

Concurrency

Delivery Guarantees

Exactly-once is hard

At-least-once is good enough when combined with Idempotence

At-most-once is good enough when loss is acceptable

Testing

Test desiderata

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

Time management

Eisenhower's urgent vs important

Eisenhower's matrix (Dwight D. Eisenhower)

Parkinson's law

Work expands so as to fill the time available for its completion. (from Wikipedia)

Law of triviality

People within an organization commonly or typically give disproportionate weight to trivial issues. (from Wikipedia)

Collaboration

Ownership

Communication

BLUF ~ TL;DR

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)

engineering-principles engineering-principles copied to clipboard

Metadata