In programming, there is a common problem known as Boolean Blindness, what it »means« to beÂ
True depends heavily on the context, and cannot be inferred by the value alone.
In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.
Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.
To save you the trouble of wading through 45 paragraphs to find the thesis, I'll give an informal version of it to you now: Any organization that designs a system...
organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
The Fairbairn threshold is the point at which the effort of looking up or
keeping track of the definition is outweighed by the effort of rederiving
it or inlining it.
The term was in much more common use several years ago.[...]
The primary use of the Fairbairn threshold is as a litmus test to avoid
giving names to trivial compositions, as there are a potentially explosive
number of them. In particular any method whose definition isn't much longer
than its name (e.g. fooBar = foo . bar) falls below the threshold.The Fairbairn threshold is named after JĂłn Fairbairn, one of the original Haskell committee members.
for each desired change, make the change easy (warning: this may be hard), then make the easy change
All problems in computer science can be solved by another level of indirection
a term originated by Andrew Koenig to describe a remark by Butler Lampson attributed to David J. Wheeler
We can solve any problem by introducing an extra level of indirection.
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
I've seen this in .signatures on USENET postings but I can no longer remember where I wrote it originally.
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
Taken to its logical extreme, this leads to the following observation, colloquially referred to as “The Law of Implicit Interfaces”: Given enough use, there is no such thing as a private implementation. That is, if an interface has enough consumers, they will collectively depend on every aspect of the implementation, intentionally or not. This effect serves to constrain changes to the implementation, which must now conform to both the explicitly documented interface, as well as the implicit interface captured by usage. We often refer to this phenomenon as "bug-for-bug compatibility."
At this point, the interface has evaporated: the implementation has become the interface, and any changes to it will violate consumer expectations. With a bit of luck, widespread, comprehensive, and automated testing can detect these new expectations but not ameliorate them.
I have come to realize that many of my struggles spring from a single underlying problem: I use my computer to interact with a big, wide, wonderful world, but the software I use imposes gratuitous restrictions on how much of that world I’m allowed to interact with at a time. It’s as if my software is forcing me to look at the world through the keyhole of a door. Hence my name for this phenomenon: The Keyhole Problem.
I think, in general, our software benefits when we use as few languages as possible, because programming languages have such powerful network effects. Embedded DSLs are usually strongly preferable to freestanding ones because we get to reuse so much knowledge and infrastructure.
There are all sorts of ways a software system might be divided, but through experience and convention, the industry has converged on LAYERED ARCHITECTURES, and specifically a few fairly standard layers. The metaphor of layering is so widely used that it feels intuitive to most developers. Many good discussions of layering are available in the literature, sometimes in the format of a pattern (as in Buschmann et al. 1996, pp. 31–51). The essential principle is that any element of a layer depends only on other elements in the same layer or on elements of the layers “beneath” it.
A useful slogan for Scheme’s macro system is that it’s a lightweight compiler API.
Due to Matthew Flatt, and quite possibly others too.
Design proprietary software as if you intended to open source that software, regardless of whether you will open source that software
a parser is just a function that consumes less-structured input and produces more-structured output. By its very nature, a parser is a partial function—some values in the domain do not correspond to any value in the range—so all parsers must have some notion of failure. Often, the input to a parser is text, but this is by no means a requirement
be conservative in what you send, be liberal in what you accept
2.10. Robustness Principle
TCP implementations should follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from
others.
One of the people that popularized the concept is Dan Olsen.
Olsen provides many examples of points in problem space: Taking notes in zero gravity, securely and quickly unlocking your phone, or filing your taxes to cite a few. We could add anything else that can be formulated as a need: Preventing a meltdown in a nuclear powerplant, finding the closest fast-food restaurant, or predicting next year’s fashion trend.
Any point in solution space corresponds to something you can build. A concrete product implementation. As engineering teams, we spend a lot of time finding points in solution space meaning designing, architecting, and engineering software products.
[E]ven Metcalfe's law understates the value created by a group-forming network [GFN] as it grows. Let's say you have a GFN with n members. If you add up all the potential two-person groups, three-person groups, and so on that those members could form, the number of possible groups equals 2n. So the value of a GFN increases exponentially, in proportion to 2n. I call that Reed's Law.
From David P. Reed's, "The Law of the Pack" (Harvard Business Review, February 2001, pp 23–4)
Data dominates. If you've 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.
The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.
Heresy! The gospel (as advocated everywhere, including elsewhere in this book) is that domain and UI should be separate. In fact, it is difficult to apply any of the methods discussed later in this book without that separation, and so this SMART UI can be considered an “anti-pattern” in the context of domain-driven design. Yet it is a legitimate pattern in some other contexts. In truth, there are advantages to the SMART UI, and there are situations where it works best—which partially accounts for why it is so common.
One of the people that popularized the concept is Dan Olsen.
Olsen provides many examples of points in problem space: Taking notes in zero gravity, securely and quickly unlocking your phone, or filing your taxes to cite a few. We could add anything else that can be formulated as a need: Preventing a meltdown in a nuclear powerplant, finding the closest fast-food restaurant, or predicting next year’s fashion trend.
Any point in solution space corresponds to something you can build. A concrete product implementation. As engineering teams, we spend a lot of time finding points in solution space meaning designing, architecting, and engineering software products.
Never ask for confirmation of a delete. Always make them undoable. If you can't make them undoable, try harder.
Remember, Undo is the king of interface idioms.
It enables strong actions with a single gesture throughout the interface.
It makes users more willing to explore and experiment.
It enables users to get into flow because they can act with confidence.
It is not a v2.0 feature, or even a v1.1 feature. Build it in from the beginning.
attempted improvement that makes things worse
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
-- From The Jargon File: www.catb.org/jargon/html/Z/Zawinskis-Law.html