Design, Composition, and Performance-- @richhickey's talk has tremendously influenced our process @roamresearch.
Here's a 5-min thread on the design part of the talk to convince you to watch the whole 1-hour vid.
Here's a 5-min thread on the design part of the talk to convince you to watch the whole 1-hour vid.
Design as we refer to it here is about
- preparing the plans (for a work to be executed), especially to plan the form and structure of that work
- marking stuff out; to make a plan and write it down.
NOT about making things look good. Most programmers are averse to both. Why?
- preparing the plans (for a work to be executed), especially to plan the form and structure of that work
- marking stuff out; to make a plan and write it down.
NOT about making things look good. Most programmers are averse to both. Why?
Because they've only experienced bad design-- monolithic plans that are overly detailed and repress creativity. It led them to do extra work with little to no returns.
So they ask, "What's the point? can't we just code?"
But good design is completely different from this.
So they ask, "What's the point? can't we just code?"
But good design is completely different from this.
Good design:
- is iterative.
- generates single-purpose components that foster reuse and survive the test of time.
- breaks things apart such that they can later be composed to solve one or more problems.
'Break apart' which things, and how? 👇🏼
- is iterative.
- generates single-purpose components that foster reuse and survive the test of time.
- breaks things apart such that they can later be composed to solve one or more problems.
'Break apart' which things, and how? 👇🏼
We'll look at 5 sections:
1. The systems requirements
2. The order in which the problem is solved/things happen
3. The place/participants
4. Information VS Mechanisms
5. Potential solutions to the problem
1. The systems requirements
2. The order in which the problem is solved/things happen
3. The place/participants
4. Information VS Mechanisms
5. Potential solutions to the problem
1. The systems requirements
When we get feature requests, we must FIRST FIND THE ACTUAL PROBLEM. Only after figuring out the issue can we try to make things that solve it.
And when we fix things, It is crucial to separate
- the causes from
- the symptoms of the problem.
When we get feature requests, we must FIRST FIND THE ACTUAL PROBLEM. Only after figuring out the issue can we try to make things that solve it.
And when we fix things, It is crucial to separate
- the causes from
- the symptoms of the problem.
Requirements can be divided further:
-What I know how to do VS What I don't know
-Domain side (satisfies X business requirement) VS Solution side ("We need to run this on AWS")
-What I know how to do VS What I don't know
-Domain side (satisfies X business requirement) VS Solution side ("We need to run this on AWS")
Finally, there's unstated requirements-- ensure you keep 'em in mind at all times.
Often these are about things your software isn't supposed to do (e.g. don't hog all memory). These can be broken down and enumerated as well.
Often these are about things your software isn't supposed to do (e.g. don't hog all memory). These can be broken down and enumerated as well.
2. The order
- Make things order-independent (commutative) so you don't have to care about how things come in. It also becomes easier to allocate the work and build distributed systems.
- Break operations apart so there's less direct calling, by using queues for instance.
- Make things order-independent (commutative) so you don't have to care about how things come in. It also becomes easier to allocate the work and build distributed systems.
- Break operations apart so there's less direct calling, by using queues for instance.
3. Place/participants
Having a design lets two teams work independently and people to work in independent languages-- you can say "run it on this machine" or "run on this tier"
We do this by adding [[indirection]]. 👇🏼
Having a design lets two teams work independently and people to work in independent languages-- you can say "run it on this machine" or "run on this tier"
We do this by adding [[indirection]]. 👇🏼
What is indirection?
Indirection makes WHAT something does completely obvious, while making to completely optional to understand HOW the thing does it.
Thus, it allows us to work with a system without completely understanding it.
Indirection makes WHAT something does completely obvious, while making to completely optional to understand HOW the thing does it.
Thus, it allows us to work with a system without completely understanding it.
Analogy: we can all use computers or drive cars without caring about the exact engine/processor lying underneath.
4. Information VS Mechanism
There's always information that our system manipulates, for instance, a set of logged in users.
BUT
That's different from your library's set class or collection class that you use to put the logged-in users.
There's always information that our system manipulates, for instance, a set of logged in users.
BUT
That's different from your library's set class or collection class that you use to put the logged-in users.
One is a piece of information; The other is a "device into which you can stick stuff"-- a "place" you can go back to you later.
5. Potential solutions
When you have one or more solutions, we want to drill down to understand:
- The Benefits (usually evident usually)
- The [[Tradeoffs]]
What part of this is not going to work?
Cost?
Does this fit the problem or is it overkill?
When you have one or more solutions, we want to drill down to understand:
- The Benefits (usually evident usually)
- The [[Tradeoffs]]
What part of this is not going to work?
Cost?
Does this fit the problem or is it overkill?
Next let's look at why design is crucial:
1. Comprehension
2. Coordination
3. Extension
4. Extension
5. Efficiency
1. Comprehension
2. Coordination
3. Extension
4. Extension
5. Efficiency
1. Comprehension
A good design is smaller than the code that implements it, so it's easier to understand what it's about.
A good design is smaller than the code that implements it, so it's easier to understand what it's about.
2. Coordination
Design is fundamental to coordination and to have multiple groups work on something. If you may have two halves of a system to implement without a plan, you won't get any work done because people will wonder which half to write.
Design is fundamental to coordination and to have multiple groups work on something. If you may have two halves of a system to implement without a plan, you won't get any work done because people will wonder which half to write.
3. Extension
Achieving reuse is not something magical or a unique attribute of APIs.
Rather, it's about breaking something down into modular blocks with nice interconnecting points.
Then, using these points, you can pull blocks out of one context and use them in another.
Achieving reuse is not something magical or a unique attribute of APIs.
Rather, it's about breaking something down into modular blocks with nice interconnecting points.
Then, using these points, you can pull blocks out of one context and use them in another.
4. Testing is greatly aided by design, but we can do better: right now we take some design constraints & specs & turn them into tests-- this is inside out.
Ideally we would embody the design inside tests & ask the computer to generate test cases & try falsifying our assertions.
Ideally we would embody the design inside tests & ask the computer to generate test cases & try falsifying our assertions.
5. Efficiency
The most frequent argument against design is "I don't have time." A bug is:
a) most expensive to fix after you've shipped,
b) and easiest to fix while designing in OmniGraffle (NOT in QA).
The most frequent argument against design is "I don't have time." A bug is:
a) most expensive to fix after you've shipped,
b) and easiest to fix while designing in OmniGraffle (NOT in QA).
Even after shipping, with design systems, you can just go back to the drawing board and split something further to fix it, versus trying to untangle a giant ball of everything.
So, what is design?
1. Design is imagining. You have to imagine potential solutions & need to want to know about everything & rush at the constraints.
If there aren't enough constraints, create your own because:
i) constraints drive creativity
ii) you want your thing to work.
1. Design is imagining. You have to imagine potential solutions & need to want to know about everything & rush at the constraints.
If there aren't enough constraints, create your own because:
i) constraints drive creativity
ii) you want your thing to work.
2. Design is a fundamentally optimistic activity.
You need to be able to face constraint after constraint and reframe them such that they benefit you.
You need to be able to face constraint after constraint and reframe them such that they benefit you.
3. Design is about making decisions
You will think of hundred times as many things as you will actually use. You don't want to think of one thing and be like,'this is what we're gonna do'-- that's actually a strategy known as [[satisficing]] 👇🏼
You will think of hundred times as many things as you will actually use. You don't want to think of one thing and be like,'this is what we're gonna do'-- that's actually a strategy known as [[satisficing]] 👇🏼
@KleInsight, author of Sources of Power, "spent many years studying naturalistic decision making: how people like firefighters, pilots and chessmasters make high-stakes decisions in real situations with time pressure, vague goals, limited information, and changing conditions..
Klein’s team of observers went into their first study (of field commanders at fire scenes) with the generally accepted model of rational decision making: Faced with a problem, a person gathers information, identifies the possible solutions, and chooses the best one...
They started with the hypothesis that because of the high stakes and extreme time pressure, fire captains would be able to compare only two options, an assumption they thought was conservative...
As it turned out, the fire commanders didn’t compare any options. They took the first reasonable plan that came to mind and did a quick mental test for possible problems. If they didn’t find any, they had their plan of action."
-- [[Black Box Thinking]] by @matthewsyed
-- [[Black Box Thinking]] by @matthewsyed
4. As a designer you want be able to say no, because your design's value is conveyed in the decisions made.
Your solution doesn't have to be perfect or do everything to users/you want-- because...
Your solution doesn't have to be perfect or do everything to users/you want-- because...
...everybody appreciates when something just works; without fiddling with what's inside of it.
This is why Apple is a trillion dollar company.
This is why Apple is a trillion dollar company.
5. And finally, design is not about leaving all options open.
You are not designing when you leave every option open and make everything configurable. You are *failing* to design and asking the user to do their own thing.
You are not designing when you leave every option open and make everything configurable. You are *failing* to design and asking the user to do their own thing.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
