2 ms·

"Will this feature be profitable if it requires X more engineers per Y users?" If the answer is yes, then I guess it's fine.

• JoeAltmaier 9y ago
  Until the code base becomes so intractable, such a dinosaur of brittle features and run-on code that nothing significant can be done without exhaustive debugging. Then no group is large enough to make good progress. Loose wads of code with random dependencies make the effort grow geometrically. No growth in team membership can keep up with that for long. The only solution is to tightly control dependencies, write good abstractions and keep to them religiously, etc. So many, many projects head off this particular cliff. They pretend to have life for a while, reducing the feature set in each drop to smaller and smaller items. Relabelling a bug fix a feature, and features overrun the sprint/release and get relabeled 'bugs' so you can keep developing through the test and release phases. So many of us recognize the syndrome. But so little gets done about it, especially in large companies.
  • humanrebar 9y ago
    > Until the code base becomes so intractable, such a dinosaur of brittle features and run-on code that nothing significant can be done without exhaustive debugging. Yes. And that gets at the point of OP. "Let me replace subsystem A so we can free up B resources per year" is a big, if it works. To throw it on the backlog for "when we get time" is self destructive in the long run.