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?
to maintain • Shorter product cycles → More stuff to maintain • Faster change of technologies (on all levels → programming languages, frameworks, infrastructure, ...) • Less loyalty of employees
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
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
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
• 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”)
• 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)
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
service? • Define the base line based and make it measurable → fully automated KPI • Offer standard solutions to meet criteria • Iterate from status quo
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.”)
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
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
devpg
jagaimogmog
michaelsewnarain
ambra_09
rumgu
cczintli_art
ray2970
_waste_of_ink_
mariomario
charmingh0rror
islaboo
chriscoyier
kimpetersen
akashhashmi
tamaranovitovic
skoyamalab
samanthasiow
tmiket
techseoconnect
irinanazarova
