Improving Software Development Flow
Five ideals for architecture, process, and culture
Slide contents
1. Improving Software Development Flow
Five ideals for architecture, process, and culture
2. Alexander Polomodov
Technical Director · architecture and delivery management
Architecture localizes change
Process makes work movement visible
Practice and culture turn improvement into habit
3. Four books build one operating system
4. Flow rests on five connected ideals
5. 01. Locality & Simplicity
Architecture localizes change and complexity
6. Architecture mirrors communication
Conway's Law
System structure reflects team communication
Inverse Maneuver
Design teams for the architecture you want
7. Invest by complexity and business differentiation
8. Choose the model before the patterns
Subdomain type and data shape determine the next choice
Core needs a domain model
Supporting / Generic may stay simple
Model count shapes the architecture pattern
Testing strategy follows architecture
9. A good boundary hides complexity behind a small interface
10. A bounded context is not a service size
Bounded context contains a model
Subdomain contains a business capability
Aggregate contains a transaction
Several services may implement one context
11. Events require explicit failure assumptions
12. Transactions and analytics optimize differently
Transactional
Predictable queries
Operation consistency
Analytical
Complex queries
Read flexibility
13. Data Mesh moves ownership into domains
DWH
Centralized team
Shared warehouse
Data Mesh
Domain owners
Data as a product
14. 02. Focus, Flow & Joy
Make work movement visible
15. Five thieves of time destroy flow
16. A flow review answers four questions
How much work finished?
How long did movement take?
What is blocked, and why?
Which thief consumed the time?
17. Inspect the distribution, not the average
Lead-time percentiles expose risk
Delivery rate shows pace
WIP reveals accumulation
Lead-time spectrum shows the tail
18. 03. Improvement of Daily Work
Engineering practices must work every day
19. Delivery speed does not require sacrificing stability
20. Five continuous delivery principles
Build quality in
Work in small batches
Automate repetitive work
Improve relentlessly · everyone owns it
21. The pipeline aligns specialists around one outcome
22. Working code is not yet good design
John Ousterhout · A Philosophy of Software Design
Your primary goal is a great design that also happens to work
23. The platform grows a paved road for development
24. 04. Psychological Safety
Culture determines what a team does with mistakes
25. An effective team needs five conditions
26. Maturity shows in the response to bad news
27. An incident review must change the system
Document the incident
Understand every contributing cause
Assign effective preventive actions
Reduce recurrence probability or impact
28. 05. Customer Focus
Customer outcome matters more than output volume
29. Connect the business outcome to the customer flow
30. You can perfectly build the wrong thing
Mary Poppendieck · Lean Software Development
The largest failure is not technical; it is building the wrong product
31. Books and diagrams in the original
IT Revolution: Phoenix · DevOps Handbook · Accelerate · Unicorn
Learning DDD · A Philosophy of Software Design
Making Work Visible · Google SRE Book
Full collection: t.me/book_cube/1440
32. Thank you!
polomodov.tech
Slides, notes, and other talks are available on the site
Alexander Polomodov, Technical Director & Fellow, T-Technologies
@ai4sdlc