The value of metaphors should not be underestimated. Metaphors have the virtue of an expected behavior that is understood by all. Unnecessary communication and misunderstandings are reduced. Learning and education are quicker. In effect, metaphors are a way of internalizing and abstracting concepts, allowing one’s thinking to be on a higher plane and low-level mistakes to be avoided. —

Fernando J. Corbató

The value of metaphors should not be underestimated. Metaphors have the virtue of an expected behavior that is understood by all. Unnecessary communication and misunderstandings are reduced. Learning and education are quicker. In effect, metaphors are a way of internalizing and abstracting concepts, allowing one’s thinking to be on a higher plane and low-level mistakes to be avoided. —

Fernando J. Corbató

“What is success?
To laugh often and much;
To win the respect of intelligent people and the affection of children;
To earn the appreciation of honest critics and endure the betrayal of false friends;
To appreciate beauty;
To find the best in others;
To leave the world a bit better, whether by a healthy child, a garden patch or a redeemed social condition;
To know even one life has breathed
easier because you have lived;
This is to have succeeded.

—Bessie Anderson Stanley (1879–1952)
Traditionally attributed to Ralph Waldo Emerson (1803–1882)”

Excerpt From: Richard N. Bolles. “What Color Is Your Parachute? 2014.” Ten Speed Press, 2013-08-13.

The gap between the best software engineering practice and the average practice is very wide—perhaps wider than in any other engineering discipline. A tool that disseminates good practice would be important. —Fred Brooks

“Until you’ve written about your software, you have no idea what you’ll be coding.”

Tom Preston-Werner, Co-Founder of Github

>>> import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!

>>> 

"The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them."

[Software Architecture in Practice, 2nd Edition By Len Bass, Paul Clements, Rick Kazman]

"An architecture is a description of system structures, of which there are several (module decomposition,process, deployment, layered, etc.). Architecture is the first artifact that can be analyzed to determine how well its quality attributes are being achieved, and it also serves as the project blueprint. An architecture serves as the vehicle for communication, is the manifestation of the earliest design decisions, and is a reusable abstraction that can be transferred to new systems. These are the things we mean when we use the word architecture."

[Software Architecture in Practice, 2nd Edition By Len Bass, Paul Clements, Rick Kazman]

"Simply stated, competitive success flows to the company that manages to establish
proprietary architectural control over a broad, fast-moving, competitive space."

C. Morris and C. Ferguson [Morris 93]

I should have no objection to go over the same life from its beginning to the end: requesting only the advantage authors have, of correcting in a [third] edition the faults of the first [two]. —

[Benjamin Franklin]

I should have no objection to go over the same life from its beginning to the end: requesting only the advantage authors have, of correcting in a [third] edition the faults of the first [two]. —

[Benjamin Franklin]

“The drive to reduce complexity is at the heart of software development” 
[McConnell 2004]

"CI involves making small changes to software and then building and applying quality assurance processes. Defects do not only occur in the code, but also appear in naming conventions, documentation, how the software is designed, build scripts, the process of deploying the software to servers, and so on. CI forces the defects to emerge early, rather than waiting for software to be fully produced. If defects are caught in the later stages of the software development life cycle, the process will be more expensive. The cost of repair radically increases as soon as the bugs escape to production. Estimates suggest it is 100 to 1,000 times cheaper to capture defects early."

[Alan Mark Berg]

"Computer programs are the most intricate, delicately balanced and finely interwoven of all the products of human industry to date. They are machines with far more moving parts than any engine: the parts don’t wear out, but they interact and rub up against one another in ways the programmers themselves cannot predict".

 [Gleik 1992]

"Extensibility is the ability to add functionality or modify existing functionality without impacting existing system functionality. You cannot measure extensibility when the system is deployed, but it shows up the first time you must extend the functionality of the system".

 [Cade and Roberts 2002]

"The most important first step in designing a data warehouse (DW)/business intelligence (BI) system, paradoxically, is to stop." —Ralph Kimball