Writing Large 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, don't 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. They don't have enough STM, the LTM is unreliable and badly structured. What should we do?
- 1,107