20+ years of software experience • Specialities: ◦ System dynamics ◦ Applied formal methods ◦ Architecture and system rescue • Engineering manager at Rebellion Defense
fail (RedHat, 2022) ◦ Average overrun budget by 27%. 1 in 6 turns into a ‘black swan’ with a cost overrun of 200% and a schedule overrun of 70% (HBR, 2022) • It’s interesting! ◦ Legacy systems are important systems. If they weren’t we’d just turn them off ◦ Legacy systems are a cultural artifact • But people always want a silver bullet and that creates space for dangerous myths to jeopardize your path to success
about the ages of things ◦ Python was invented before Java ◦ LISP is older than COBOL ◦ Many of the “new” languages of today are already 10 years old. • Age doesn’t matter as much as maintenance ◦ Is the language/framework still being developed? Are there security patches? ◦ How easy/hard is it to integrate it with modern protocols? ▪ Awful Java middle layers 🤮
• Lot’s of awful configurations can work, what are the hidden costs? ◦ Works once != works at scale • If you decide to migrate, have a clear and specific reason why the “new” technology is the right choice.
COBOL programmers have remained stable for the last 30 years despite people dying/retiring • There are many skills that aren’t explicitly taught in college that we’re not freaking out about: ◦ SRE ◦ Frontend ◦ Mobile • COBOL systems are almost exclusively enterprise systems. It takes a lot of time to get good at running enterprise systems so it makes sense that people come to COBOL later in life.
question of how your organization wants to invest ◦ Train incoming hires in preferred language (Google does this!) ◦ Train existing employees in new tech and figure out the migration • Up to date and well written documentation is gold • Testing, especially unit tests help engineers learn about their systems
often fuels overconfidence leading to: ◦ Poor estimations in scope ◦ Too many requirements ◦ Delays, budget overruns • Once the software is rewritten the long slow process of migrating off the old system begins • Rewriting also means retraining/onboarding engineering and operations
the existing system • Rewrites spend a lot of time reproducing functionality already available. In order to be successful they need to demonstrate value without adding new functionality ◦ Noticeable (by non-engineers) increase in performance ◦ Friendlier and more intuitive user interfaces ◦ More stable and reliable • Maintain discipline around MVP: new functionality should be sprinkled in gradually
cloud is great and probably the right thing • But also full of hidden costs ◦ 10K tax bill! ◦ Data egress ◦ Different fee structures in different regions ◦ Over-scaling, poor resource utilization • Economies of scale • Specialized concerns: ◦ Foreign nationals ◦ Conflicts of interest ◦ Vendor lock in ◦ Mainframe emulation
you have economies of scale • Do your research: different vendors have specialized environments and offerings for unique security and business concerns • Identify where assumed cost savings will come from ◦ Decrease in staff? ◦ Not investing in hardware? ◦ Increase in scale? • How much is “everything”? ◦ Can the data originate in the cloud? ◦ Can the end user of the data be moved to the cloud?
or any other COTS product (nothing against Salesforce ❤) • ….Or “no code” solutions that auto generated applications • Tools are built and optimized for specific use cases • Extensions, plugins and custom modifications introduce potential bugs and vulnerabilities • Interfaces can be unintuitive • “Junk” code diminishes operations
you need fits what the COTS solution was designed for from the beginning, go for it! • Can do something does not mean does well • How are these customizations tracked? (version control, supply chain security) how are they reproduced? (backups, failovers) • Is this system internal or customer facing? • Who’s going to be responsible when something breaks? Is there a support contract?
and we monitor its health • We have tested how the system recovers when something fails • There is someone responsible for keeping this system healthy and that person has the resources they need to be successful • System owners can make changes confidently, without fear of triggering an outage • We know where we are spending our money • We don’t look for solutions that will make all our problems go away so we don’t have to invest in our technology anymore!
have different challenges than startups ◦ Maintaining operations at scale is particularly bad • Modernization is a useful word because it helps us find each other and share the best advice • But modernization can also make it sound like the solution is to remove the old stuff when the problem is often neglect
come from effective strategies ◦ “This technology is too old.” → Upgrading to superior hardware ◦ “All the COBOL programmers are dying/retiring.” → Investing in people ◦ “It’s better to completely rewrite this.” → Realigning requirements ◦ “We must move everything to the cloud.” → Leverage managed services ◦ “We can just replace this with Salesforce” → Better security through standards • The difference is attitude: “silver bullet” vs having clear measurable goals to make a system better
mbellotti
oracle4engineer
tacck
cyberagentdevelopers
16bitidol
tenshoku_draft
takumiogawa
sugamasao
tammyeverts
kitsuya0828
mrbobbytables
lycorp_recruit_jp
kakehashi
jacobian
samanthasiow
eileencodes
tanoku
keavy
irinanazarova
productmarketing
denniskardys
thoeni
hannesfritz
ddemaree
