Software Development Quotes

DI is the ability to inject the implementation of a contract into a target. IoC is the ability to vary the implementation.

Software being "Done" is like lawn being "Mowed". by @ourfounder

Essentially, all models are wrong, but some are useful
-- George E. P. Box Empirical Model-Building and Response Surfaces (1987)

There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

Kent Beck
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.
When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature. 
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. 
Refactoring: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing the observable behavior of the software.
Often you'll see the same three or four data items together in lots of places: fields in a couple of classes, parameters in many method signatures. Bunches of data that hang around together really ought to be made into their own object. 
Optimism is an occupational hazard of programming: feedback is the treatment. 

Never change test and implementation at the same time.
Only use pair programming for the hard part of your system.
DRY is the enemy of decoupled
Premature Optimisation is the root of all evil in programming (Donald Knuth)

As the application grows it's imperative to be able to reason about its constituent parts in isolation. Conversely, there is a
lot of value in building code out of components that are testable and reusable by nature.
Abstraction is the elimination of the irrelevant and the amplification of the essential.

two laws of software development: all nontrivial code has defects, and the probability of nontrivial defects increases with code size. 
https://www.computer.org/cms/Computer.org/ComputingNow/issues/2015/04/mso2015020010.pdf

As the writer Antoine de Saint Exupéry famously noted, “Perfection is achieved not when there is nothing more to add, but when there is nothing more to remove.”

Interface Seggregation Principle: Replace header interfaces with role interfaces

Conway's law
Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

Postel's law - robustness principle
Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept").
Examples: out of order packages

Be wary about returning null, it makes your API an order of magnitude harder to understand
It is OK to make classes public if they properly protect their invariants

Fast feedback is a core tenet of Agile and critical to the success of a project. Using a separate QA team slows down this feedback, creates an “us and them” mentality and makes it more difficult to build quality into the software. Testing should be a tightly integrated activity and isn’t something the team can outsource. We recommend integrated teams where testers work closely with developers instead of having testing as a separate organization.

In the sorts of commercial projects I've worked on in the last 20 years, I've learned that new technologies or new paradigms should be adopted for good business reasons only. If it isn't going to save me budget over the lifetime of the project, over and above a more established technology that can deliver the same final system, then at best it's novelty for the sake of novelty and at worst it's pure technological masturbation.

Leaders who don't listen will eventually be surrounded by people who have nothing to say. - Andy Stanley

CAP theorem
Consistency (all nodes see the same data at the same time)
Availability (a guarantee that every request receives a response about whether it succeeded or failed)
Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system)

If you have a lot of querying and reporting requirements that you don’t know up front then a document database like RavenDB or CouchDB is a better choice. Likewise if you have minimal querying requirements and performance is important than you would be better suited to using Redis.

ACID (Atomicity, Consistency, Isolation, Durability)

DDD
Value object vs entity - ISBN for book lenders & registration code for library employees 
http://epic.tesio.it/doc/manual/shared_identifiers.html

A system ”fails” whenever it does not behave as designed.
http://epic.tesio.it/2012/12/05/exceptions-are-the-norm.html

Asynchronous processing models can be highly efficient but are not without challenges. If the real world writes the best stories, then
maybe we can learn something from Starbucks about designing successful asynchronous messaging solutions.

Write-off
This is the simplest strategy: do nothing, or discard what you’ve done. This might seem like a poor plan, but in the reality of business, it might be acceptable. If the loss is small, building an error-correction solution might be more expensive. Furthermore, it might
slow down the flow of messages, which reduces system throughput.

Retry
Compensating actions
Transaction coordinator (two-phase commit)

The real world is often asynchronous. Our daily lives consist of many coordinated but asynchronous interactions (such as reading and replying to email or buying coffee). This means that an asynchronous messaging architecture can often be a natural way to model
these types of interactions. It also means that looking at daily life can help us solve our messaging problems.