4 ms·

Having code bloat doesn't mean that a process is broken, it comes down to what you are optimizing for. Facebook optimizes for getting new code into production f

Having code bloat doesn't mean that a process is broken, it comes down to what you are optimizing for. Facebook optimizes for getting new code into production fast. I don't know if @ktRolster stopped reading right after the line he quoted, but his point is addressed in the article: Our code base has grown organically and its internal dependencies are very complex. We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult. On top of that, the idea that the scaling constraints of our source control system should dictate our code structure just doesn't sit well with us.

ktRolster 10y ago
Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult. I read it, but none of those things make me think better of their code.
- personjerry 10y ago
  Ah, but the perfectionist engineer is rarely satisfied with production code quality. Hence we have another important part of a software company--the managers, who optimize for things like getting features out more quickly, things that are effective at doing what companies seek: make money.
  - serge2k 10y ago
    > the managers, who optimize for things like getting features out more quickly, things that are effective at doing what companies seek: make money Which works great until the day you wake up to realize your code base has become an incomprehensible mess and your engineering systems are outdated and your competitors are shipping better software at a faster pace. I'm not really disagreeing, I'm just saying a balance must be struck. Really hate companies that view anything but feature work as a loss.
    - spicyj 10y ago
      As someone who works at Facebook on a team dedicated to improving developer efficiency (React), I assure you that FB sees value in long-term maintenance and tooling improvements. All the teams building features do too.

ktRolster 10y ago

Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult. I read it, but none of those things make me think better of their code.

personjerry 10y ago
Ah, but the perfectionist engineer is rarely satisfied with production code quality. Hence we have another important part of a software company--the managers, who optimize for things like getting features out more quickly, things that are effective at doing what companies seek: make money.
- serge2k 10y ago
  > the managers, who optimize for things like getting features out more quickly, things that are effective at doing what companies seek: make money Which works great until the day you wake up to realize your code base has become an incomprehensible mess and your engineering systems are outdated and your competitors are shipping better software at a faster pace. I'm not really disagreeing, I'm just saying a balance must be struck. Really hate companies that view anything but feature work as a loss.
  - spicyj 10y ago
    As someone who works at Facebook on a team dedicated to improving developer efficiency (React), I assure you that FB sees value in long-term maintenance and tooling improvements. All the teams building features do too.