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

More Decks by Adam Tornhill

Other Decks in Programming


  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. DRM Shared DRM/AMD … Aggregate Files Into Architectural Building Blocks

    @AdamTornhill agsupport.c internal.c … connector.c DRM Shared
  7. 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
  8. Inter-Team Coordination in a Layered Architecture Team #1 Team #2

    Team #3 Team #4 51% 23% 22% @AdamTornhill Team #5
  9. 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?
  10. Some Common Arguments for Microservice Loose Coupling Team Autonomy Independent

    Scaling of Services, Deployed Independently @AdamTornhill
  11. 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
  12. @AdamTornhill Low Team Autonomy because the architecture is technically oriented,

    which misaligns with the work of the team, which is feature/use case oriented.
  13. A Failure Due To Lack of Modularity @AdamTornhill Will Small

    And Modular Services Solve The Problem?
  14. 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 ...
  15. 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
  16. 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
  17. @AdamTornhill Conway’s Law and Its Impact on Modularity Recommendation Align

    your Architecture with the Problem Domain to Create Natural Team Boundaries
  18. 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.
  19. 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
  20. 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
  21. @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
  22. 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/
  23. 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
  24. “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?
  25. @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]