3 ms·
For very large codebases, this is often not an option. I know of very large 'let's write Cobol mainframe to Java' projects, burning 10s of millions of euros, th
by tluyben2 6y ago
For very large codebases, this is often not an option. I know of very large 'let's write Cobol mainframe to Java' projects, burning 10s of millions of euros, that were just thrown away because they could not actually get it working in the end.
And this is not limited to mainframe projects; it happens with (large) more recent projects (Java/C# mostly) as well.
- TameAntelope 6y agoFor sure, it's not an option for these existing systems. But when building a new system, design it and plan for it to be retired when certain criteria are met (e.g. when it hits 100 reqs/sec, 3 years from first release, when LOC hits 100k).
- tluyben2 6y agoAbsolutely: I was only commenting on a blind 'just rewrite it' as that will always be the first reaction of tech people and quite often it is simply not feasible. But agreed, by design it can work.
- barbarbar 6y agoThat raises an interesting question. Are there any such rewrites that have succeeded? I have mainly heard that it is either failures or not done.
- TameAntelope 6y agoIf you are asking me if I’ve experienced a successful rewrite? Yes, numerous, and the more successful ones have happened as a result of planning. I’ve also been part of rewrites that have gone poorly, due to a lack of planning, where the legacy software fails in unexpected and unanticipated ways, which requires a rushed attempt to fix the issue (which fails) and a subsequent rushed attempt to replace the core functionality when the fix doesn’t work (and also fails because “core” tends to be larger than you initially think). Knowing ahead of time when software isn’t going to be useful any more isn’t really an option, it’s just an acceptance of what is already going to happen.