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

  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

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

More from Johann-Peter Hartmann