Elon Musk’s SpaceX company continues to revolutionize the aerospace industry, has greatly reduced the cost of space travel, and is on track to put mankind on Mars in our life time. What are the Principles to this Success, and what does it have to do with Pull Requests and Feature Branching ? We’ll look at these Principles to explain how Pull Requests and Feature Branching are often detrimental to software delivery and are likely slowing you down. We’ll explore alternatives like Trunk Based Development and Pair Programming and walk through a more efficient coding workflow to help speed up your software delivery project.

1. SPACESHIPS, PULL REQUESTS AND FEATURE BRANCHING
A Principles-Based approach to Software Development
Victor Szoltysek

2. PULL REQUESTS - BAD *
FEATURE BRANCHING - BAD *
ORIGINAL TITLE:
* More often then we think

6. HOW IS SPACEX
ACHIEVING THIS ?

7. Hint: Rocket Design remains largely the same.

8. Reusable Rockets ?
Space Shuttle
1981

9. Vertically Landing Rockets ?
DC-X
1993

10. Stainless Steel Construction
or Liquid Methane Propellent
?
Centaur
1962

11. Don’t just follow the trend. You may have heard me say that it’s
good to think in terms of the physics approach of first principles.
Which is, rather than reasoning by analogy, you boil things down
to the most fundamental truths you can imagine and you reason
up from there.
Elon Musk (SpaceX)

12. GOAL
PRINCIPLES
RULES / PRACTICES

13. SpaceX Starship

14. Goal : Get Mankind to Mars

15. Goal : Minimize Cost per Pound of Payload to Orbit

16. Principle : Optimize for the Whole

17. Principle : Tight Feedback

18. Principle : Allow for Failure

19. STARSHIP DESIGN GOAL
▸ Get Man to the Moon
▸ Minimize Cost per Pound of Payload to Orbit
DRIVING PRINCIPLES (instead of Rules / Practices)
▸ Optimize for the Whole
▸ Tight Feedback
▸ Allow for Failure

20. WHAT CURRENT “GOOD INTENTIONED”
PROCESS IS STALLING STARSHIP ?
(last launch was March 21 2021)

21. FAA Environmental Assessment Approval

22. PULL REQUESTS (The FAA Environmental Assessment of Software)

23. PULL REQUESTS
▸ Positive Intentions:
▸ Ensure Code Quality
▸ Often Net Negative (as a whole) Outcomes:
▸ “Biked Shedded” Code Reviews
▸ Including Ivory Tower CTO’s that need to nitpick and feel important
▸ Slower Integration Feedback
▸ Refactoring (Code Quality) is Harder
▸ Alternatives Exists !!
▸ If truly required — then I would argue it’s a symptom of a larger problem

25. FEATURE BRANCHES (LONG LIVED)

26. FEATURE BRANCHES (LONG LIVED)
▸ Positive Intentions:
▸ Features are fully isolated until ready
▸ Often Net Negative Outcomes:
▸ Slower Integration Feedback
▸ CI often isn’t being run for non-trunk
▸ Increase in Merge Hell
▸ Refactoring (Code Quality) is Harder
▸ Alternatives Exists !!

27. ALTERNATIVE
WORKFLOW *
* For a typical Agile Team starting from scratch (Green
fi
eld)

28. SOFTWARE PROJECT GOAL
▸ Make Great Products
▸ Increasing Value ($$), decrease Cost and decrease Risk
DRIVING PRINCIPLES (instead of Rules / Practices)
▸ Optimize for the Whole (think trade-offs)
▸ Tight Feedback (Continuous Integration)
▸ Allow for Failure (but catch issues quicker - MMTD / MTTR)

29. IN LIEU OF MANDATED PULL REQUESTS
▸ Skip Pull Requests for Trivial Changes
▸ Allow Non-Dev’s / Non-Technical People to Commit
▸ For Trivial Code Review Stuff (Syntax etc) :
▸ Static Code Analysis (local and CI + alerting)
▸ Established “Team Charter” of Best Practices with Team Buy-In
▸ No Code Ownership / “Leave Campsite Cleaner then you Found It”
▸ Refactoring is Signi
fi
cantly easier when you don’t have long lived branches !
▸ Asynchronous Code Reviews ™ after Merge (~weekly) or upon creation of a Release
▸ Optional and Targeted Pull Requests for Review by SMEs
▸ Pair Programming / Mob Code Reviews for Education + Junior Developers

30. DEALING WITH INTERNAL CORPORATE MANDATES
▸ Do the Pull Request at the Release Branch and NOT Trunk
▸ Add name of second “pair” in commit message when Pair Programming (in lieu
of pull request)

31. IN LIEU OF FEATURE BRANCHING
▸ Follow Trunk-Based Development
▸ Commit Frequently, including un
fi
nished code
▸ Tag with Story Number - include WIP tag
▸ Code Clean Up / Refactoring is separate
▸ Need to Drop Mandated Pull Requests for this to work
▸ Prefer “Implicit” Feature Flags (should be most of the time)
▸ Focus on detecting and resolving issues quicker (MTTR, MTTR) instead of Perfection
▸ Perfect is the Enemy of Good

33. STREAMLINING EXISTING PROJECTS
▸ Have a Culture of Psychological Safety and Experimentation
▸ Allow the Questioning of Established Rules / Practices
▸ Run Ef
fi
cient Retrospectives
▸ Try and Measure Process Improvements
▸ Start Small
▸ Make Pull Request Optional for Trivial Changes
▸ Mitigate “Bike Shedding”
▸ Allow PR approvals with no comments
▸ Use Static Code Analysis for Nitpicking
▸ Have a coding standards team charter (with team buy in)
▸ Have purpose to PRs — leverage SME’s and point them in the right direction
▸ Prefer Alternative Code Reviews methods
▸ Pair Programming - Create Psychological Safety for This (leave ego at the door)
▸ Post Merge Code Reviews (asynchronous)
▸ Static Code Analysis
▸ Mob Code Reviews

34. WHEN TO CONSIDER MANDATED PULL REQUESTS / FEATURE BRANCHING
▸ Open Source Code
▸ Very large teams
▸ Large percentage of Junior Developers (especially offshore)
▸ Consider alternatives (like splitting the code base!)
▸ For Feature Branching — Large Scale Refactoring
▸ Remember to regularly pull from master

35. OTHER COMMON SOFTWARE PRACTICES TO QUESTION
▸ Kubernetes and Containers
▸ 80% Unit Test Coverage
▸ Microservices
▸ Single Page Apps
▸ Functional Programming
▸ Non-Blocking Asynchronous Programming

36. THINKING IN PRINCIPLES
Victor Szoltysek
victor_szoltysek@mac.com