Slide 1

Slide 1 text

@AdamTornhill — MEET THE SOCIAL SIDE OF YOUR ARCHITECTURE —

Slide 2

Slide 2 text

@AdamTornhill A Psychological Programmer? 2015 2018

Slide 3

Slide 3 text

@AdamTornhill The Human Brain: Shortcuts and Workarounds

Slide 4

Slide 4 text

Controversy: The Person or the Situation? “ 91% of the differences in people’s behaviour in different situations could not be accounted for by personality tests. ” Mischel (1968) @AdamTornhill

Slide 5

Slide 5 text

@AdamTornhill The System = Code + People + Organization “Personality” “Situation”

Slide 6

Slide 6 text

@AdamTornhill How Readable Code Becomes Unreadable

Slide 7

Slide 7 text

@AdamTornhill Mental Models for Code Mental Model Reality

Slide 8

Slide 8 text

The Mythical Man-Month Brooks’s Law: “Adding manpower to a late software project makes it later”. Time to completion @AdamTornhill Soft Risks with Overstaffing Motivational Factors? Social Loafing

Slide 9

Slide 9 text

@AdamTornhill A Coordination Bottleneck?

Slide 10

Slide 10 text

@AdamTornhill The Tragedy of Software Design: The Organisation that builds the System is Invisible in the Code itself

Slide 11

Slide 11 text

Are We Treating Symptoms Instead of the Real Issues? Merge conflicts? Defects due to unexpected feature interactions? Long-Lived feature branches? Code that’s hard to understand? Code that’s hard to refactor since it’s also under active development? @AdamTornhill

Slide 12

Slide 12 text

Start: Detect Inter-Team Coordination needs in Code Team #1 Team #2 Team #3 Team #4 51% 23% 22% 0.0 1.0 Fractal Value: M. D’Ambros, M. Lanza, and H Gall. Fractal Figures: Visualizing Development Effort for CVS Entities. Normalize the fragmentation to the range 0..1.0 @AdamTornhill

Slide 13

Slide 13 text

VCS — A Behavioral Data Source Commit: b557ca5 Date: 2016-02-12 Author: Kevin Flynn Fix behavior of StartsWithPrefix 8 27 src/Mvc.Abstractions/ModelBinding/ModelStateDictionary.cs 1 10 src/Mvc.Core/ControllerBase.cs 1 1 src/Mvc.Core/Internal/ElementalValueProvider.cs 1 39 src/Mvc.Core/Internal/PrefixContainer.cs Commit: fd6d28d Date 2016-02-10 Author: Professor Falken Make AddController not overwrite existing IControllerTypeProvider 8 1 src/Core/Internal/ControllersAsServices.cs 48 0 test/Core.Test/Internal/ControllerAsServicesTest.cs 13 0 test/Mvc.FunctionalTests/ControllerFromServicesTests.cs Commit: 910f013 Date :2016-02-05 Author Lisbeth Salander Fixes #4050: Throw an exception when media types are empty. 20 1 src/Mvc.Core/Formatters/InputFormatter.cs Social Information A Time Dimension Progress on Tasks Co-changing Files @AdamTornhill

Slide 14

Slide 14 text

DRM Shared DRM/AMD … Aggregate Files Into Architectural Building Blocks @AdamTornhill agsupport.c internal.c … connector.c DRM Shared

Slide 15

Slide 15 text

Social Ways to Fail With Software Architecture @AdamTornhill Øredev 2018

Slide 16

Slide 16 text

Controller View Services ORM Repository @AdamTornhill Layered Classics: MVC, MVP, MVVM, etc. Model Controller View Controller View Services ORM Repository DAL Controller View Services ORM Repository DAL ViewModels Business Change Coupling 30-70% of all commits modify multiple layers

Slide 17

Slide 17 text

Inter-Team Coordination in a Layered Architecture Team #1 Team #2 Team #3 Team #4 51% 23% 22% @AdamTornhill Team #5

Slide 18

Slide 18 text

One team per technical component makes each boundary a coordination point => long lead times coordination Layer Data Layer SQL Layer Layer Component Teams Work on different features => everything becomes a coordination bottleneck Feature Teams SQL Layer Data Layer Layer Layer @AdamTornhill Component our Feature Teams: Pick Your Poison?

Slide 19

Slide 19 text

@AdamTornhill Component our Feature Teams: Pick Your Poison?

Slide 20

Slide 20 text

Some Common Arguments for Microservice Loose Coupling Team Autonomy Independent Scaling of Services, Deployed Independently @AdamTornhill

Slide 21

Slide 21 text

Coordination Needs in Distributed Monoliths* 3 teams 4 teams 4 teams * http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html 58% 24% 15% Team #1 Team #2 Team #3 Team #4 @AdamTornhill

Slide 22

Slide 22 text

@AdamTornhill Low Team Autonomy because the architecture is technically oriented, which misaligns with the work of the team, which is feature/use case oriented.

Slide 23

Slide 23 text

@AdamTornhill Loose Coupling Team Autonomy Independent Scaling of Services, Deployed Independently

Slide 24

Slide 24 text

A Failure Due To Lack of Modularity @AdamTornhill Will Small And Modular Services Solve The Problem?

Slide 25

Slide 25 text

The Two Forms Of Accidental Complexity Complex Parts Complex Inter-Dependencies @AdamTornhill

Slide 26

Slide 26 text

Subscription Service Change Coupling Sign-Up Service Recommendations Service Change #1 Change #2 Change #3 Time Read More: http://www.empear.com/blog/software-revolution-part3/ @AdamTornhill ...

Slide 27

Slide 27 text

Microservices and the Cost of Change When EstimatedProfit changes, 5 other services have to be modified as well When EstimatedConversions changes, 7 other services have to be modified as well @AdamTornhill

Slide 28

Slide 28 text

The Change Coupling Bomb: An Inter-Team View 3 teams 5 teams 2 teams Services or Distributed Objects? @AdamTornhill Subscription Costs Payment Accepted Payment Received Payment Options Customer Growth

Slide 29

Slide 29 text

@AdamTornhill Loose Coupling Team Autonomy Independent Scaling of Services, Deployed Independently

Slide 30

Slide 30 text

Microservices or “Microservices”? When you design a software architecture, you’re also doing social design. @AdamTornhill

Slide 31

Slide 31 text

Align Your Architecture and Organisation @AdamTornhill Øredev 2018

Slide 32

Slide 32 text

@AdamTornhill Conway’s Law and Its Impact on Modularity Recommendation Align your Architecture with the Problem Domain to Create Natural Team Boundaries

Slide 33

Slide 33 text

Microservices? Yes, possible but not a guarantee (as we have seen…). An expensive and high-discipline architecture. Microservices wont’ cure your dependency blues. @AdamTornhill Team-sized, partitioned by Business Capabilities, not data Small teams: + Less coordination overhead + Motivational: minimises the risk for social loafing 
 with each contribution being recognised.

Slide 34

Slide 34 text

UI (feature set) UI and/or REST API (another feature set) An Alternative to Layers: Package By Component @AdamTornhill For more details, see http://www.codingthearchitecture.com/2015/03/08/package_by_component_and_architecturally_aligned_testing.html Business Capability A Business Capability B Business Capability C ..but with the database as coordination bottleneck! AKA the black-hole of maintenance efforts and change coupling

Slide 35

Slide 35 text

Services Repositories ORM Services SQL UI (feature set) REST API (another feature set) Consistent Macro Architecture, Diverse Micro Designs @AdamTornhill Business Capability A Business Capability B Business Capability C

Slide 36

Slide 36 text

@AdamTornhill Express Natural Team Boundaries in Your Architecture Business Capability A Business Capability C Business capabilities as architectural building blocks Business Capability B Natural Team Boundaries

Slide 37

Slide 37 text

Tools Code Maat: command line, open source (GPL) https://github.com/adamtornhill/code-maat adam$ git shortlog -s —- src/user_service/ 8 D. Cooper
 7 Bob
 2 N. Cross 37 B. Horn Mining data with Git Example: Coordination per component CodeScene: Behavioral Code Analysis https://codescene.io/

Slide 38

Slide 38 text

Conway’s Law Is An Over-Simplification @AdamTornhill

Slide 39

Slide 39 text

We attribute the same observable behaviour to different factors depending on whether it concerns our group or another one. The Fundamental Attribution Error We overestimate personality factors when explaining the actions of others. “Our” work “Their” work @AdamTornhill

Slide 40

Slide 40 text

Provide Broad Knowledge Boundaries @AdamTornhill For more details, see https://pragprog.com/book/atevol/software-design-x-rays

Slide 41

Slide 41 text

“The extent to which you can implement new features without calling a grand staff meeting is the ultimate test of an architecture’s success.“ https://pragprog.com/book/atevol/software-design-x-rays @AdamTornhill A Clean or Dirty Architecture?

Slide 42

Slide 42 text

@AdamTornhill Blog on Software Evolution, Technical Debt, and Behavioral Code Analysis https://www.empear.com/blog/ Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis https://pragprog.com/book/atevol/software-design-x-rays [email protected] Further Reading Showcases with Interactive Analysis Results https://codescene.io/showcase