hey everyone! I’m killick, I’ve been a programmer ...
# introduce-yourself
i
hey everyone! I’m killick, I’ve been a programmer for 15+ years. I work in non-profit orthopedic healthcare. Right now I’m uuubsessed with legacy systems migration (aka been in it for so long I have to justify its value). questions that haunt me rn: • why do ppl assume rebuilding from scratch is easier? • is small incremental migration always more desirable? • are there any general criteria for picking a migration strategy? (cf Patterns of Legacy Displacement) • is there a negative correlation between familiarity with a system and the perceived difficulty of migrating it? or vice versa? anyhow, this is my latest rabbit hole. previous (and evergreen) ones include uiua, coordinate systems, a multi-user simultaneous room-scale development environment, and the indie web. happy to be here!
e
Fellow uiua folks who are also interested in thinking through ways to support and modernize legacy systems unite!
g
Just in case: A lot of legacy systems work was done for the Y2K issue. Search for "design recovery".
m
So cool to have you here! Piggybacking on your current focus, I wonder if you have any thoughts on the design of new systems. Especially from the perspective of somebody dealing with them long after they've been deployed. Looking back, are there any features that would make the maintenance / migration easier? Or maybe remove the need for migration altogether?
i
i’m definitely gonna think more on that — great topic. off the top of my head: • keep things modular • refactor constantly (working effectively with legacy code is a great book, as is the pragmatic programmer) • have good and appropriate test coverage (i’m the problem it’s me) • have your dependency version upgrades as automated as you can