Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Meet the Social Side of Your Architecture (DevExperience)

Meet the Social Side of Your Architecture (DevExperience)

Software projects often mistake organizational problems for technical issues and treat the symptoms instead of the root cause. The main reason is that the organization that builds the system is invisible in our code. From code alone, we cannot tell if a module is a productivity bottleneck for five different teams, or whether our microservice boundaries support the way our codebase evolves or not. This session closes that gap by taking a behavioral view of code combined with insights from social psychology to measure aspects of software development that we haven't been able to capture before. You learn how this information lets you detect modules with excess coordination needs, measure how well your architecture supports your organization, suggest and guide refactorings, as well as why Conway's law is an oversimplification. To make it specific, each point is illustrated with a case study from a real-world codebase.

Adam Tornhill

April 19, 2019
Tweet

More Decks by Adam Tornhill

Other Decks in Programming

Transcript

  1. @AdamTornhill
    — MEET THE SOCIAL SIDE OF YOUR ARCHITECTURE —

    View full-size slide

  2. @AdamTornhill
    A Psychological Programmer?
    2015
    2018

    View full-size slide

  3. @AdamTornhill
    The Human Brain: Shortcuts and Workarounds

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. @AdamTornhill
    How Readable Code Becomes Unreadable

    View full-size slide

  7. @AdamTornhill
    Mental Models for Code
    Mental Model
    Reality

    View full-size slide

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

    View full-size slide

  9. @AdamTornhill
    A Coordination Bottleneck?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. DRM Shared
    DRM/AMD

    Aggregate Files Into Architectural Building Blocks
    @AdamTornhill
    agsupport.c
    internal.c

    connector.c
    DRM Shared

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  18. 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?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. Align Your Architecture and Organisation
    @AdamTornhill Øredev 2018

    View full-size slide

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

    View full-size slide

  32. 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
    Small teams:
    + Less coordination overhead
    + Motivational: minimises the risk for social loafing 

    with each contribution being recognised.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  35. @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

    View full-size slide

  36. 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/

    View full-size slide

  37. Conway’s Law Is An Over-Simplification
    @AdamTornhill

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  40. “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?

    View full-size slide

  41. @AdamTornhill
    Blog on Behavioral Code Analysis
    http://www.empear.com/blog/
    Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis
    https://pragprog.com/book/atevol/software-design-x-rays
    Try the Social Analyses in CodeScene:
    https://codescene.io/
    [email protected]

    View full-size slide