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

One Week later

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

Design Patterns

ca 1995

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 :/







Domain Driven Design



















ca 2005

DevOps: Move Complexity to places where you can automate it.

Faster Understanding
with more Observability

Faster Feedback =
Less things to remember


























ca 2013


  • 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?


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



5 lines of λ


50 lines of

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/

  • JavaScript/TypeScript for

  • 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


Use a helpful environment 3


The Secret: How to become a
10-times programmer

  1. Organize coding dojos at in your team
  2. Do a lot of pair programming
  3. Practice clean code
  4. Train until 5 of you are 3 times more effective
  5. 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


Trained on existing fixes from Github


Analyses your code and recommends known patches



  • 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) {}
      } catch (FileNotFoundException _e) {
      } catch (IOException _e) {

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
Loading comments...

More from Johann-Peter Hartmann