Informal laws

From apm
(Redirected from Informal law)
Jump to: navigation, search
This article is a stub. It needs to be expanded.

"Laws"


  • Drexler's law (I hereby declare it as such as this was his statement) – "What we can do depends on what we can make."

  • Goodhart's law – Generalization by Marilyn Strathern: "When a measure becomes a target, it ceases to be a good measure."

Coding

  • Greenspun's tenth rule – "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." (there are no nine preceding rules)

  • Fundamental theorem of software engineering (FTSE) (David Wheeler)
    "We can solve any problem by introducing an extra level of indirection." – With it's extension! ...
    "Except for the problem of too many layers of indirection." (humorous but serious)

Principles

"Form follows X" / "Design follows X"


  • Form follows function – When the shape of an object primarily relates to its intended function or purpose.
    This is usually the result when designing at the limit of what's possible under tight constraints.
    When the limits imposed by physical law leads to the emergent discovery of the shape of a technical artifact.

This could also be called "Design for functionality (DFF)" matching the following one.


DFM could be seen as special case of "form follows function" in the sense of
"form follows limits and constraints in available possible and practical manufacturing technologies" or shorter
"form follows manufacturability"


  • "Design for recycling (DFR)" or "Form follows recyclability" – I just made this one up ad-hoc here to complete the product cycle.

Related: Recycling


Summary (the bold ones are the established terms):

  • Design for manufacturing (DFM)
  • Design for funcionality (DFF)
  • Design for recycling (DFR)
  • Design for assembly (DFA)
  • Form follows manufacturability
  • Form follows function
  • Form follows recyclability
  • Form follows assemblability

Musk's 5 step design process

  • (1/5) Sanity check specifications / requirements. Do they even make sense?
  • (2/5) Delete / add-in stuff – as critical part of the process. – "The best part is no part."
  • (3/5) simplify / optimize
  • (4/5) accelerate cycle-time
  • (5/5) automate

Avoid doing the whole sequence in reverse.

Related

External links