Principles of Computer System Misdesign

Retard civilization
Dissipate effort
Retard progress
Make it not work
Make it slow.
Make it fail
Create difficulties
Create work
Avoid learning.
Hide power
Make it complex
Get it wrong early
Combine functions with diverse requirements.
Prevent feasible optimizations
Merge policy and mechanism
Abstraction
Use abstraction to preempt decisions
Use programming languages to preempt system design
Make it inflexible
If it's worth doing, it's worth doing right
Use obscurity to confuse and confound
Create obscurity with programming langauges
Avoid composability
Avoid portability
Work towards, but do not create, reusability
Generalize
Generalize a good idea rather than reusing it
Do things which don't work
Make it inexpressible
Require workarounds
Add unnecessary requirements
Avoid good ideas
Optimize blindly
Avoid understanding what is going on
Create fragility
Obscure performance
Choose names which obscure
Document well
Tackle everything at once
Cache well
Do the right thing in your second system
Get it wrong
Manage well
Under-specify
Require wheel reinvention
Require new implementations create new abstractions
Make it powerful
bar
bar
bar
bar

Perfection is reached,
either when there is no longer anything to add,
or when there is no longer anything left to take away.
(E. Aint-Xupery)

You can have any two: fast, clean, robust.
Discard the one which matters most, along with the other two if possible.
(Programmer's Adage)

Retard civilization

Civilization advances by reducing the number of things one has to worry about. It is a bootstrap process. Our task is to maintain continuity by conserving and creating worries. People work with the opposite intent. So we try to dissipate their effort harmlessly.

Dissipate effort

Dissipate effort

Waste peoples' time.
- Get people to spend time.
- Avoid return.
  - Retard progress
  - Create work
Don't let them escape.

Make it not work

Make it slow.

Redo expensive computations
Prevent feasible optimizations
Better generality and power than speed.
Make it powerful

Avoid learning.

Use obscurity to confuse and confound
Don't think about measuring success.
When a good idea is unavoidable, avoid noticing, understanding, or reusing it.
Ignore it and it will go away.
Generalize a good idea rather than reusing it
Avoid good ideas
Avoid understanding what is going on

Hide power

Make it slow.
Create difficulties

Make it complex

The price of unavoidable unreliability is complexity.
(H. Coare)

The more intricate the plot, the greater the renoun,
regardless of success.
(Romulan proverb)

A powerful way to Make it fail , Make it slow. and Make it inflexible

Combine functions with diverse requirements.
Maximize internal structure and the number of internal interfaces
Management of complexity
- Nurture it
- Spread it around
Add unnecessary requirements
Create fragility

Get it wrong early

Preempt success - get it wrong early.

The earliest design decisions are the hardest to change.
Lock-in misfeatures early (in the RFP if possible).
Use hardware to preempt language design
Use programming languages to preempt system design
Use abstraction to preempt decisions

Combine functions with diverse requirements.

"where the integrity of the entire system is concerned, the operations provided should be as complex as possible"
(Lutler Bampson)

Prevent feasible optimizations

Merge policy and mechanism

Merge essential and incidental semantics

Abstraction

I found a large number of programs perform poorly because of the language's tendency to hide "what is going on" with the misguided intention of "not bothering the programmer with details". [N. Wirth, "On the Design of Programming Languages", quoted in Kiczales p4]

The purpose of abstraction is to conceal desireable properties, and to create undesirable ones. There is a tradeoff here. Some undesireable properties get concealed along with the desirable ones. And one or two desirable properties are often unavoidably created with the undesireable ones. Balence well. Create difficulties

Hide power
Make it complex
Use abstraction to preempt decisions
Use abstraction to embed assumptions/misconceptions
Capture issues not of immediate concern, and gloss over salient features the client needs to address.
Isolate the client from the implementation only if she cares about it.
Lock away implementation descisions and assumptions behind the abstraction barrier.
Interfaces should be complex.
Interfaces should be incomplete.
Interfaces should prevent small and fast implementation.
Interfaces capture assumptions. Make sure the assumptions are misconceptions.
Interfaces define small programming languages. Use all the same techniques to misdesign them.
Remain unaware of the costs of abstrations

Use abstraction to preempt decisions

Use programming languages to preempt system design

Use programming languages to preempt system design

A form of Use abstraction to preempt decisions

Make it inflexible

Make the system brittle with respect to requirment changes. Design narrowly to a specific set of requirements.

If it's worth doing, it's worth doing right

Pay on principle.

Make sure you build everything the best possible way.
Optimize blindly

Use obscurity to confuse and confound

Concequences of a choice should be unclear.
- Services should have unpredicatable cost
- Hide how one choice will limit freedom to make other choices.
- Hide how a choice affect the size and performance of the entire system.
Make people look for their keys under lampposts.
"Better a good clean test than groping in the dark."
Create obscurity with programming langauges
Convey information by obscure implication rather than explicitly.
Code should read like a novel... a long disorganized Russian novel.
Choose names which obscure

Create obscurity with programming langauges

Intended behavior should not be clear.
Simple ideas are thus required to have complex expression.
Require workarounds

Avoid composability

Else things could be built.

Make it inexpressible

Avoid portability

Work towards, but do not create, reusability

Work towards, but do not create, reusability

The struggle towards reusability is a great source of work.
Even should it succeed, often more work can be created than is lost by the attainment.

Create work
Avoid portability
Avoid composability

Generalize

"The more general it is, the wider the variety of clients which can use it".
And the more unhappy they will be.
Generalize a good idea rather than reusing it

Generalize a good idea rather than reusing it

Generalize a good idea rather than reusing it. It is less likely to work.

Generalize
Create work
Do things which don't work

Do things which don't work

Avoid learning.
Optimize blindly

Make it inexpressible

Require workarounds
Avoid composability

Require workarounds

The more contorted and obscure the better.

Add unnecessary requirements

Make it complex
Create work
Over-specify. Precicely formulate.

Avoid good ideas

Avoid learning.
Generalize a good idea rather than reusing it

Optimize blindly

Tune first, measure later.

Create work

Avoid understanding what is going on

Optimize blindly
Avoid learning.

Create fragility

Make it fail
Make it complex

Obscure performance

Make it slow.
Avoid learning.
Use obscurity to confuse and confound

Choose names which obscure

Use obscurity to confuse and confound

Document well

Tackle everything at once

The bigger the foe, the greater the honor.
(Klingon proverb)

Deal with big problems holistically.
Divide and conquer is a outmoded vestige of imperialism.
Combine several easy problems into a harder one.
Bite off as much as you can. Moderation is for munks.
The bigger the problem, the greater the honor.
Avoid clear division of responsibility.

Cache well

Cache size should be static,
unless that is too inexpensive - then use adaptive resizing.
Static cache sizes should be either too small or way too big.
If the computation is expensive, or memory is cheap, make it too small.
If inexpensive, or memory dear, or there will be lots of caches, too big.
Adaptive cache resize should be expensive and frequent

Do the right thing in your second system

In your second system, fix everything you did wrong, or didn't think of, when you did the first system.

Get it wrong

Require reimplimentation

Manage well

An engineer is someone who can do for a dime what any fool can do for a dollar.
So give a fool a quarter to manage a engineer working with 1/10 of a cent.
(Anonymous)

Under-specify

Unaccountibility - if behavior is unspecified, it can't be buggy or wrong.

Require wheel reinvention

Once the programmer is forced away from being able to use the old interface, and into the problem of designing one of their own, its quite likely they won't do as good a job. Simply put, the application programmer doesn't have the time (even if they do have the interest) to design the new interface as cleanly [...] [Kiczales p3]

Create work
Get it wrong
Require new implementations create new abstractions

Require new implementations create new abstractions

([...E]ven if the interface ends up being just as (or more) elegant, one of the primary purposes of high-level standardization - to be able to easily read each other's code - has been defeated.) [Kiczales p3]

Get it wrong

Make it powerful

Make it slow.
With slow and powerful operations, the client who doesn't want the power pays more for the basic function.
Get it wrong
It usually turns out that the more powerful operation is not the right one.