5 ms·

> Worse of all, though, his concern that “We aren’t building the right thing” will be replaced with “We aren’t building the thing right.” To be fair, part of a

> Worse of all, though, his concern that “We aren’t building the right thing” will be replaced with “We aren’t building the thing right.” To be fair, part of an engineer's job is to give her opinion on when you're not building the right thing because you're building the right thing in the wrong way. Building something with 10-100X more cost, unacceptable bug rates, or a pivot-unfriendly design means losing money in many (most?) contexts.

JoeAltmaier 9y ago
It can always be debugged in the next sprint! Just pick up another item from the board and keep coding; if we get behind we'll just hire some more college grads.
- humanrebar 9y ago
  "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.

JoeAltmaier 9y ago

It can always be debugged in the next sprint! Just pick up another item from the board and keep coding; if we get behind we'll just hire some more college grads.

humanrebar 9y ago
"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.