Writing Big Software
with a Small Brain.

A new solution in
a month?
I'll do it in two weeks.

It's a prototype, right?
We are going to throw it all away, right?
#greenfield #ftw


Two weeks later
-
You know the overall structure
-
The APIs are simple
-
Development is fun
-
Low cognitive load
-
Fast Changes
-

Boss: Hey, Your software is great!
Let's add some features ...

Brilliant, the customers love it.
They just need one more thing.

"Hmm, i thought there was already a method for this ... but nevermind..."

6 months later ...

-
You know the overall structure -
The APIs are simple -
Development is fun-
Low cognitive load -
Fast Changes
-

Uncle Bob
“reading versus writing is
well over 10 to 1.
We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.”

Reading to Writing
10 to 1 !
Fast comprehension >
Fast keyboard

How we understand software
(with a small brain)

Top-Down Comprehension:
-
how seniors do it
-
Hypotheses based on existing knowledge
-
Search for places to prove or falsify them

Bottom-Up Comprehension:
-
Search for things you recognize
-
Combine known units to understand
larger sections

Default for most Developers:
Start with top-down analysis
Apply Bottom-up when You
recognize something
while validating
How many items can your brain handle at the same time?

Your Working Memory:
max. 7 (+2) items

Developers chunk and slice code to understand it.


Known Patterns &
Ignored Lines

Spaghetti Monolith

Predictable Implementations
a.k.a.
Design Patterns
ca 1995

Monoliths:
As long your brain stays small
large software stays slow.
Project Size | Lines of Code/Day/Dev |
---|---|
10.000 | 10 - 125 |
100.000 | 5 - 100 |
1.000.000 | 3,5 - 50 |
10.000.000 | 1.5 - 25 |
Source: Steve McConnell, Software Sizing

Layered Architecture:
I still need to understand every layer for debugging :/

Catalog
Domain Driven Design
Inventory
Orders
Payment
ca 2005
DevOps: Move Complexity to places where you can automate it.

Faster Understanding
with more Observability

Faster Feedback =
Less things to remember
Catalog
Service
Elastic
Search
MicroServices
Inventory
Service
PostgreSQL
Orders
Service
MySQL
Payment
Service
-
ca 2013
MicroServices
- can be deployed independently -> fast feedback
- provide one business capability -> smaller domain
- have no dependency on central governance or external data management
- use on automated infrastructure / integration / deployment
Microservices: Software that fits in your Head
Dan North
Couldn't just somebody else care about the complicated stuff?


Serverless
Automate All The Things!

ca 2015
- should be "service-full"
- Function as a Service / Lambda /λ
- Serverless databases / Aurora etc
- SQS, SNS, ELB, Route53,
- function as a deploy unit
- Pay-as-you-go
- Scaling is a solved problem
- Event-driven
- You won't get fired for choosing AWS


Observability included
Text


Text
5 lines of λ
50 lines of
configuration
But ...
Ok, and what should i do about it?

Rule #1:
Optimize your brain, not optimize technology.
The amount of time understanding sourcecode has not decreased notably in 30 years.

Rule #2
Mastery in One Language
Needed for:
-
Top-Down Comprehension
-
Design Patterns
-
Craftership
Mastery in One Language
5 years, full-time
-
"10.000 hours for mastery"
-
backed by scientific research
for program comprehension
Coding-Dojos & Pair Programming:
- smart algorithms
- common idioms
- design patterns
- solution strategies

Rule #3
One more language...
Understand your work/
co-workers:
-
JavaScript/TypeScript for
Browser-Dev
-
Kotlin/Swift/Dart for
mobile Development
-
Python/R for data analytics
- Go for fast services ...

Rule #4: a helpful environment 1

IDE Support
Use a helpful environment 2

Automation
Use a helpful environment 3

Observability
The Secret: How to become a
10-times programmer
- Organize coding dojos at in your team
- Do a lot of pair programming
- Practice clean code
- Train until 5 of you are 3 times more effective
- Done, that's even better than one 10 times programmer!

What comes next
Genesis & Prophet (2016)
Automatic error detection & Patch Generation
16 of 39 Patches are correct

DeepCode.ai
Trained on existing fixes from Github
Analyses your code and recommends known patches

askbayou.com
- Military Project
- Create new Programs based on sketches
import java.io.*;
import java.util.*;
public class TestIO {
void read(File file) {
{
/// call:readLine type:FileReader type:BufferedReader
}
}
}
import java.io.*;
import java.util.*;
import java.io.FileReader;
import java.io.File;
import java.io.IOException;
import java.io.FileNotFoundException;
import java.io.BufferedReader;
public class TestIO {
void read(File file) {
{
FileReader fr1;
BufferedReader br1;
String s1;
try {
fr1 = new FileReader(file);
br1 = new BufferedReader(fr1);
while ((s1 = br1.readLine()) != null) {}
br1.close();
} catch (FileNotFoundException _e) {
} catch (IOException _e) {
}
return;
}
}
}
So, i still have to work in future?
The amount of time understanding sourcecode has not decreased notably in 30 years.

We didn't win, but we didn't loose, either.
Creating Big Software with a Small Brain
By Johann-Peter Hartmann
Creating Big Software with a Small Brain
Humans are not made to create software. Especially our brains do not help a lot. There don't have enough STM, the LTM is unreliable and badly structured. What should we do now?
- 217