Slide contents

1. 1. Improving Software Development Flow

   Five ideals for architecture, process, and culture

2. 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. 3. Four books build one operating system

4. 4. Flow rests on five connected ideals

5. 5. 01. Locality & Simplicity

   Architecture localizes change and complexity

6. 6. Architecture mirrors communication

   Conway's Law

   System structure reflects team communication

   Inverse Maneuver

   Design teams for the architecture you want

7. 7. Invest by complexity and business differentiation

8. 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. 9. A good boundary hides complexity behind a small interface

10. 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. 11. Events require explicit failure assumptions

12. 12. Transactions and analytics optimize differently

    Transactional

    Predictable queries

    Operation consistency

    Analytical

    Complex queries

    Read flexibility

13. 13. Data Mesh moves ownership into domains

    DWH

    Centralized team

    Shared warehouse

    Data Mesh

    Domain owners

    Data as a product

14. 14. 02. Focus, Flow & Joy

    Make work movement visible

15. 15. Five thieves of time destroy flow

16. 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. 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. 18. 03. Improvement of Daily Work

    Engineering practices must work every day

19. 19. Delivery speed does not require sacrificing stability

20. 20. Five continuous delivery principles

    Build quality in

    Work in small batches

    Automate repetitive work

    Improve relentlessly · everyone owns it

21. 21. The pipeline aligns specialists around one outcome

22. 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. 23. The platform grows a paved road for development

24. 24. 04. Psychological Safety

    Culture determines what a team does with mistakes

25. 25. An effective team needs five conditions

26. 26. Maturity shows in the response to bad news

27. 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. 28. 05. Customer Focus

    Customer outcome matters more than output volume

29. 29. Connect the business outcome to the customer flow

30. 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. 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. 32. Thank you!

    polomodov.tech

    Slides, notes, and other talks are available on the site

    Alexander Polomodov, Technical Director & Fellow, T-Technologies

    @ai4sdlc