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

That’s my experience ...

So, what’s the problem? There are 10

● 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?

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

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

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

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

Turn it off! Well ...

Local Global Internal External

No content

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!

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

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

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

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

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

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”)

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)

Again, Care For the Slow One’s

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

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

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.”)

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

Set The Course Early 20% of next Sprint Legacy

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

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

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