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.

Transcript

1. @AdamTornhill — MEET THE SOCIAL SIDE OF YOUR ARCHITECTURE —
2. @AdamTornhill A Psychological Programmer? 2015 2018
3. @AdamTornhill The Human Brain: Shortcuts and Workarounds
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
5. @AdamTornhill The System = Code + People + Organization “Personality” “Situation”
6. @AdamTornhill How Readable Code Becomes Unreadable
7. @AdamTornhill Mental Models for Code Mental Model Reality
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
9. @AdamTornhill A Coordination Bottleneck?
10. @AdamTornhill The Tragedy of Software Design: The Organisation that builds the System is Invisible in the Code itself
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
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
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
14. DRM Shared DRM/AMD … Aggregate Files Into Architectural Building Blocks @AdamTornhill agsupport.c internal.c … connector.c DRM Shared
15. Social Ways to Fail With Software Architecture @AdamTornhill Øredev 2018
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
17. Inter-Team Coordination in a Layered Architecture Team #1 Team #2 Team #3 Team #4 51% 23% 22% @AdamTornhill Team #5
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?
19. Some Common Arguments for Microservice Loose Coupling Team Autonomy Independent Scaling of Services, Deployed Independently @AdamTornhill
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
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.
22. @AdamTornhill Loose Coupling Team Autonomy Independent Scaling of Services, Deployed Independently
23. A Failure Due To Lack of Modularity @AdamTornhill Will Small And Modular Services Solve The Problem?
24. The Two Forms Of Accidental Complexity Complex Parts Complex Inter-Dependencies @AdamTornhill
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 ...
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
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
28. @AdamTornhill Loose Coupling Team Autonomy Independent Scaling of Services, Deployed Independently
29. Microservices or “Microservices”? When you design a software architecture, you’re also doing social design. @AdamTornhill
30. Align Your Architecture and Organisation @AdamTornhill Øredev 2018
31. @AdamTornhill Conway’s Law and Its Impact on Modularity Recommendation Align your Architecture with the Problem Domain to Create Natural Team Boundaries
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.
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
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
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
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/
37. Conway’s Law Is An Over-Simplification @AdamTornhill
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
39. Provide Broad Knowledge Boundaries @AdamTornhill For more details, see https://pragprog.com/book/atevol/software-design-x-rays
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?
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/ adam.tornhill@empear.com