How Technical Problems Cause Organizational Friction • Adam Tornhill • GOTO 2023 (Category Architecture)

Interesting. report from Adam Tornhill sociotechnical smells (presentation available here). The bottom line is that our modern systems are very complex and involve both software and the people who write it. (It wasn't until LLMs started doing it themselves.). Balancing is difficult because the code doesn’t directly explain the sociotechnical context of who wrote it and why, and what changes it made. Adam Tornhill We use behavioral code analysis, where we combine code analysis with data on how commands interact within the code, for example, who makes changes and how parallel it happens, what the cohesion and coupling parameters look like, and how difficult it is to maintain code with high technical debt. I wonder what a year before that. Adam I had a great talk on the topic of prioritization of debt, and I told. If we return to behavioral code analysis, the autohor suggests, using them, to reduce organizational friction and focus on a number of common tasks. Identify architectural coordination bottlenecks and understand technical root causes Visualize implicit dependencies between teams and then act to separate them. (decouple) team Identify knowledge risks by measuring the bus factor. Learn how to soften it. Communicate the scaling risks inherent in Brooks’ Law by showing how it affects your delivery Go beyond the technical impact of knowing how bad code leads to low morale and increased exhaustion

Sociotechnical factors that the author calls sound something like this. 1. The overcrowded system When too many people work on the same system and give too little exhaust) 2. Coordination bottlenecks in the code A problem with a lot of changes to the same files in your system by people from different teams. It is very difficult to maintain a mental code model, so this leads to more bugs and more complex changes. It seems that this part would still be useful approaches from the whitepaper.Architecture Anti-patterns: Automatically Detectable Violations of Design Principles"that I mean." told earlier 3. A propagating cost of change Change coupling and how changes in one place trigger a large number of changes elsewhere if change coupling is high. Just recently, I told Kent Beck's book.Clean design" ("Tidy First?")There was a good deal of change couplin. 4. Dependent work crossing team boundaries The author is talking about the reverse maneuver of Conway, where we need to choose the structure of the teams so that it matches the desired architecture. Plus, we need to organize the architecture of the system so that it fits well into the problem domain and allows you to organize natural boundaries for teams. 5. Unhealthy code with a low Truck Factor The author remembers the bus factor and the people who are dropping out, and then shows that if it is superimposed on unhealthy code, then we get a big problem. Conventionally, if we lose an expert in entangled code, our knowledge of the details of the implementation of systems is greatly reduced and changes become longer and more expensive.

P.S. The author has a website. https://codescene.com/ Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis. The license costs $300 a year per developer.

P.P.S. Whitepapers referred to by the author

• The business impact of Code Quality
• On-boarding costs in unhealthy code
• Happiness and the Productivity of Software Engineers
• The Influence of Organizational Structure On Software Quality

#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Architecture #TechDebt #Management