Actually, I have a slightly unrelated question: what are the issues that affect 100MLOC codebases that aren't so important for smaller projects? This is something people sometimes bring up, but I'm not too sure what exactly they mean by it.
Actually, I have a slightly unrelated question: what are the issues that affect 100MLOC codebases that aren't so important for smaller projects? This is something people sometimes bring up, but I'm not too sure what exactly they mean by it.
Getting ~100KLOC of C++ compiling on a "new" compiler has been something that's taken me a few days before. Not too unreasonable.
100MLOC is literally 1000x the size - which extrapolating from "a few days" would mean it'd take me 8-14 years to fix up on my own were I to do it by hand. Or more realistically, the pace of change/growth on a codebase of that size probably outstrips my ability to convert it.
So now even a simple straightforward task such as fixing up technically nonstandard C++ syntax to standard C++ that multiple compilers will happily accept, is a task requiring either automated code modifications (scary!) or a large coordinated team effort. If 100 people working together are, optimistically, 100x as efficient as me alone - i.e. there's no overhead in terms of coordination and planning - it will still take them around a month to do the job via brute force.
;)
Yeah, easy to say in hindsight, but we won't figure out how to budget better or call out bad business plans if we don't start recognizing it when it happens.
Unless there is a very good reason that convinces the business sponsors that it's OK to spend a few man years on it. Switching to a shinier version of the programming language usually isn't.