People leave the company, software stays

Transcript

1. People leave the company,
   software stays
   Wenn das Wissen die Firma verlässt und die Software bleibt
   

   View Slide

2. That’s my experience ...
   

   View Slide

3. So, what’s the problem?
   There are 10
   

   View Slide

4. ● Bill Hinshaw
   ● CEO and Founder of Cobol Cowboys, LLC
   ● Worked the age of 75 for different financial
   institutions to maintain their Cobol based
   applications
   Source:
   https://www.manager-magazin.de/unternehmen/artikel/us-banken-brauchen-it-kraefte
   -manager-holen-cobol-veteranen-zurueck-a-1143632.html
   #1: Who knows this guy?
   

   View Slide

5. #2: Who knows these kind of applications?
   Source:
   https://twitter.com/theburningmonk/status/134
   1413011668553730/photo/1
   

   View Slide

6. Sounds like a different story?
   It’s not! It will be even worse!
   

   View Slide

7. This Is The Future!
   ● More digitalisation → More stuff to
   maintain
   ● Shorter product cycles → More stuff to
   maintain
   ● Faster change of technologies (on all
   levels → programming languages,
   frameworks, infrastructure, ...)
   ● Less loyalty of employees
   

   View Slide

8. How to deal with software - if there is
   only little knowledge left?
   

   View Slide

9. Turn it off! Well ...
   

   View Slide

10. Local
    Global
    Internal
    External
    

    View Slide

11. View Slide

12. Strive For Transparency
    ● Non-Tech people don’t understand the complexity of technology
    ● Make it tangible (e.g. what’s impact)
    ● Use KPI (churn, service maturity, ...)
    ● Repeat! Redundancy drives relevance!
    

    View Slide

13. Maintain A “Tech Improvement List”
    ● Get the full picture, involve everyone
    ● Prioritize and consider step-fixed costs
    ● Use as input for roadmap planning
    ● As a tech leader: Support overall
    prioritization
    

    View Slide

14. Offer Different Software Development Modes And Apply
    The Right Mode To Your Project
    Ideas
    ●
    ● Will result in a prototype/
    MVP
    Emerging Products
    ● Time to market matters
    ● Iterative approach
    (solution will be
    changed/ enhanced/
    replaced in the future)
    Core Services/ Products
    ● Needs to scale
    ● May stays “forever”
    ● Allows fast development
    but will no care about
    every detail
    ● Will result in slow
    development but a robust
    solution
    

    View Slide

15. Optimize For Maintainability Onboarding
    ● Have some up-to-date overall documentation in place (system architecture,
    domain, ...)
    ● Documentation of core decisions (e.g. ADR)
    ● Pay attention to readability
    ● Favor automation (every manual process will break sooner or later)
    ● Simplicity is king, make it a habit/ principle
    

    View Slide

16. Separation helps
    ● Modularisation on code level (e.g. Micro-Service, Lambda Functions)
    ● Isolation and clear responsibility on system level
    

    View Slide

17. Don’t Fall in Love With The Shiny New Technology
    Syndrome
    Be aware: There is always a technology which is handling one aspect better than
    the technologies you already have in use.
    Focus on the big things rather than the details:
    ● Maturity of technology
    ● Available ecosystem (e.g. support)
    ● Organisational impact
    Credits to: Boring Technology Club
    

    View Slide

18. Aim for a small “Tech-Zoo”
    ● Choose your technologies wisely
    ● Organise them in a Tech Portfolio/ Tech Radar
    ● Apply Standards where individual solutions don’t add value
    ● Most importantly: Remove technologies!
    ● Apply a threshold (“For every new technology, another one has to leave”)
    

    View Slide

19. How To Introduce New Technologies
    Asses Trial Adopt On hold
    ● Research &
    Prototyping of
    promising
    technologies
    ● No use in
    production
    ● Deepen experience
    ● Limited usage in
    production for side
    application
    ● Allow usage
    technology in large
    scale across all
    systems
    ● No usage for new
    projects
    ● Constant review to
    define
    End-of-Lifetime
    ● Only purpose
    statement required
    ● Requires a consent
    decision (absence
    of objections) based
    on assessment
    ● Requires consensus
    decision (two-thirds
    majority)
    ● Decision criteria
    Developer
    experience, Costs of
    change, ...
    ● Requires consensus
    decision (two-thirds
    majority)
    

    View Slide

20. Again, Care For the Slow One’s
    

    View Slide

21. Minimize Bus Factor
    1. Have an overview of (key) knowledge areas
    2. Identify gaps → Use skill management (for
    technologies as well as domain knowledge)
    3. Close them (Pair programming, trainings, brown
    bag sessions)
    Def: “[...] minimum number of team
    members that have to suddenly
    disappear from a project before the
    project stalls due to lack of
    knowledgeable or competent
    personnel.”
    Source: Bus Factor
    

    View Slide

22. Implement Service Maturity Model
    Goal: What’s the state of a service?
    ● Define the base line based and make it measurable → fully automated KPI
    ● Offer standard solutions to meet criteria
    ● Iterate from status quo
    

    View Slide

23. Run Software Development as Craftsmanship
    ● Focus on well-crafted software and strive for mastery
    ● Not only responding to change, but also steadily adding value
    ● Make use of the pull system
    ● Apply Scout Principle (“Always leave the code better than you found it.”)
    

    View Slide

24. Set The Course Early
    Source::THE PRODUCT PORTFOLIO MATRIX
    Investments
    Investments change over product lifecycle but
    decrease earlier compared to benefits
    

    View Slide

25. Set The Course Early
    20% of next Sprint Legacy
    

    View Slide

26. Force Company Into Zero-Legacy-Policy
    ● Legacy software is unlike wine, aging doesn’t help*
    ○ Knowledge, commitment and motivation will decrease over time → It’s just gets more
    expensive.
    ● Give freedom & responsibility to where it needs to be handled
    ● Introduce Zero-Issue-Policy like for bugs to keep legacy software manageable
    ● How to handle existing stuff? Just start, use status quo as threshold and
    constantly reduce it
    * actually also not true for most wines
    

    View Slide

27. Local
    Global
    Internal
    External
    Run Software Development
    as Craftsmanship
    Strive For Transparency
    Minimize Bus Factor
    Set The Course Early
    Small “Tech-Zoo”
    Zero-Legacy-Policy
    Implement Service
    Maturity Model
    Set The Course Early
    Separation helps
    Optimize For Onboarding
    Offer Different Software
    Development Modes
    

    View Slide

28. People leave the company,
    software stays
    Wenn das Wissen die Firma verlässt und die Software bleibt
    

    View Slide