GOTO notes: Simplicity


GOTO notes: Simplicity

Simplicity, The Way of the Unusual Architect
Dan North

The Second System effect - the first system is usually built under pressure. If we could do it again… So we cram all this stuff in…

1. We see a repeating phenomenon. We see patterns.
2. We create abstractions.
3. The abstractions become a framework. (We get clever.)
We, as Enterprise Architects, are trying to help.
4. People start to subvert the framework.
5. Finally, sometimes, simplicity grows out of adversity.

We are programmed to see structure.
Our brains are programmed to fill stuff in.
The reflexive loop - we pre-program ourselves (from former beliefs) to select data. Before we form an opinion, we’re already filtering data. Unconsciously.
Cognitive bias.

We choose to optimize for generality, or flexibility, or reuse.
Cost-per-use is a particularly toxic metric.
We complify when we should simplicate.
Complify is when you make something harder than it needs to be.

Own it. “My name is Dan, and I’m a complexiholic.”

Fred Brooks - Identify accidental complexity.
Essential complexity - intrinsic; how hard the problem is
Accidental complexity - introduced in how you try to solve the problem
The paradigm you choose to approach the problem with may affect the complexity.

Anything we’re doing, we can get feedback as we go.
Use time-boxes to challenge your progress.

Simplicity is different from familiarity.
We’re used to crappy software.
But if someone moves our cheese (the MS Office Ribbon), we get upset.
Bring someone in from outside and say, “this is my world. What’s dumb?” Unfamiliar people bypass the Boiling Frog syndrome.

Question every dependency. We’re paid to solve problems, not write software.
If the components are too big to do reasonable testing on, have smaller components. (He’s not a fan of DI Containers by default - there’s always a cost/trade-off.)

Pull value rather than pushing a solution. Don’t make the problem fit your model of the world.

Ask: What is actually slowing me down?
If you weren’t blind to these things, you’d be crying. (Confirmation bias)
Again, you may need to bring someone else in.

Get a pair. Or a bath duck. Say it out loud.

We tend to solve the wrong problem.
TDD is solving a second-order problem - the system I’m trying to design won’t fit in my head, so I break it down.
Because the pain goes away, you won’t worry about simplifying things.

Ask what is the first-order problem?

We create levels and levels of complexity, then we say “this is really hard.”

Simplicity leads to adaptability.
Avoid thinking around corners.

Defer decisions to create options. (Read up on Real Options.)

You want a roadmap that you unfold, not an itinerary. Based on feedback, you can determine where you want to go. Defer decisions; you may have new information.

“Maximize the work not done” - Kent Beck

We are programmed to complify.
The real goal is to simplicate.
Very few problems are intrinsically hard. How we look at it, or how we choose to solve it, often make it hard.
Work in small groups. Discuss things. Pair.
Anyone who starts a sentence with “why don’t we just…” should be listened to.

Always assume that there is a simple solution.

47 layers of indirection - cushion between you and the problem.
Is there a need for a particular layer?
Ask “where’s the value?”
Avoid doing things by default - “I always use tool/technique X.”

“Subjective feeling of obviousness.”
Make understandability a goal.
If it doesn’t fit in my head, make it fit in my head.
Avoid painkillers - feel the pain and deal with it.

Your Host:
Copyright © 2000-2013 by William Sorensen. All rights reserved.