4 ms·

> a magic wand that makes source-to-source changes on a 100MLOC codebase trivial is pure fantasy Actually, I have a slightly unrelated question: what are the i

> a magic wand that makes source-to-source changes on a 100MLOC codebase trivial is pure fantasy 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.

perlgeek 11y ago
It's basically impossible to review and touch the whole code base if it's 100MLOC. 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.
- forrestthewoods 11y ago
  Are those projects likely to switch to c++11 or c++14 which dint have breaking changes? It seems unlikely. In which case why not break things?
  - adrianN 11y ago
    Those kind of projects tend to use an ancient proprietary compiler that is no longer maintained.
- plonh 11y ago
  Google brags about constantly doing large scale refactoring on heir codebase.
MaulingMonkey 11y ago
The sheer size of the thing is a big problem. 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.
- cpeterso 11y ago
  A large codebase is more likely to contain older, less maintained code. It didn't get to be large overnight! ;)
  - MaulingMonkey 11y ago
    So you're saying it's going to be even more effort to get compiling on a new compiler... that my 8-14 years estimate was low-balling the problem...? ;)
    - humanrebar 11y ago
      The problem was when someone budgeted for new code but didn't budget for this sort of maintenance. If there wasn't enough money for that, then the problem was the business plan. 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.

perlgeek 11y ago

It's basically impossible to review and touch the whole code base if it's 100MLOC. 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.

forrestthewoods 11y ago
Are those projects likely to switch to c++11 or c++14 which dint have breaking changes? It seems unlikely. In which case why not break things?
- adrianN 11y ago
  Those kind of projects tend to use an ancient proprietary compiler that is no longer maintained.
plonh 11y ago
Google brags about constantly doing large scale refactoring on heir codebase.

MaulingMonkey 11y ago

The sheer size of the thing is a big problem. 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.

cpeterso 11y ago
A large codebase is more likely to contain older, less maintained code. It didn't get to be large overnight! ;)
- MaulingMonkey 11y ago
  So you're saying it's going to be even more effort to get compiling on a new compiler... that my 8-14 years estimate was low-balling the problem...? ;)
  - humanrebar 11y ago
    The problem was when someone budgeted for new code but didn't budget for this sort of maintenance. If there wasn't enough money for that, then the problem was the business plan. 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.