3 ms·

> Repaying during good times and taking on debt in projects with high stakes and fixed deadlines. I agree this is an amazing strategy when you can do it! > No

> Repaying during good times and taking on debt in projects with high stakes and fixed deadlines. I agree this is an amazing strategy when you can do it! > None is willing to take on the risks associated with technical debt repayment. What do you think they are afraid of? What risks are there? Is it possible to mitigate these risks in some way?

carlmr 8y ago
>What do you think they are afraid of? What risks are there? Is it possible to mitigate these risks in some way? Not OP, but usually there are no (trusted) unit tests.
- lowry 8y ago
  IMO, unit tests, integration tests, TDD, BDD, etc do not matter as much as the size of the codebase. If your system has millions of lines of code, you are doomed and no amount of unit tests can help you.
  - hutzlibu 8y ago
    I believe thats why modularization was invented?
    - lowry 8y ago
      Modularization per se does not work. What works is administrative boundaries. Once a product reach a certain size, the team should be split up.
      - hutzlibu 8y ago
        "Once a product reach a certain size, the team should be split up." That is also called modularization.
lowry 8y ago
The downsides of the technical debt repayment are visible to everyone: new bugs are introduced, changes are made and users have to adapt. There is trouble for everyone who is not the developer. The upside is visible only to developers in the short term. Sometimes a technical debt repayment may require a big change in business. I saw a banking system where the authorization framework was based on impresonation of users. Repaying the technical debt would mean going over all contracts and adjusting their conditions while developers implemented a more traditional role-based access control. Such a change was so unrealistic that middle management did not even talk about it until some day the project got outsourced and most developers — reassigned to other projects.

carlmr 8y ago

>What do you think they are afraid of? What risks are there? Is it possible to mitigate these risks in some way? Not OP, but usually there are no (trusted) unit tests.

lowry 8y ago
IMO, unit tests, integration tests, TDD, BDD, etc do not matter as much as the size of the codebase. If your system has millions of lines of code, you are doomed and no amount of unit tests can help you.
- hutzlibu 8y ago
  I believe thats why modularization was invented?
  - lowry 8y ago
    Modularization per se does not work. What works is administrative boundaries. Once a product reach a certain size, the team should be split up.
    - hutzlibu 8y ago
      "Once a product reach a certain size, the team should be split up." That is also called modularization.

lowry 8y ago

The downsides of the technical debt repayment are visible to everyone: new bugs are introduced, changes are made and users have to adapt. There is trouble for everyone who is not the developer. The upside is visible only to developers in the short term. Sometimes a technical debt repayment may require a big change in business. I saw a banking system where the authorization framework was based on impresonation of users. Repaying the technical debt would mean going over all contracts and adjusting their conditions while developers implemented a more traditional role-based access control. Such a change was so unrealistic that middle management did not even talk about it until some day the project got outsourced and most developers — reassigned to other projects.