4 ms·

I've been CTO (well, IT Director) for 3 years and I saw no particular problem with technical debt. I just handled it the same way I would handle financial debt.

by lowry 8y ago

I've been CTO (well, IT Director) for 3 years and I saw no particular problem with technical debt. I just handled it the same way I would handle financial debt. Repaying during good times and taking on debt in projects with high stakes and fixed deadlines. It all depends on the industry as well. My CTO experience was in News and Media, where software is rewritten quite often and does not have any business value by itself. I am now in a consulting position in the banking industry. Things are different there. None is willing to take on the risks associated with technical debt repayment. It accumulates endlessly. Once it reaches a point where no local developer would work on the project, the project is handed over to Asian sweatshops which support it indefinitely.

maxxxxx 8y ago
That's also a problem in medical software. People are so risk averse that they avoid relatively small changes until the whole thing comes crashing down eventually. I have also seen the trend that good developers start to leave and the only people left are low quality developers or outsourcing companies who don't care about what they work on.
- lowry 8y ago
  Another aspect is the size of the business and the related dilution of power and responsibility. Repaying technical debt in production software means introducing new bugs, instability, change. Users will have to adapt, business KPIs will suffer. The upside won't be visible. No sane middle manager would agree to that, because this will negatively impact his career path. As a solution, I advise organizing work in maintenance teams rather than by project. Having personal responsibility for each feature or process or product also helps.
  - maxxxxx 8y ago
    In the end working on large long term projects that a lot of people depend on just is not much fun :). Working on smaller projects where you can make quick changes is much more satisfying.
waterlink 8y ago
> 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.
pmarreck 8y ago
> None is willing to take on the risks associated with technical debt repayment. This risk is vastly mitigated with good test coverage. https://smile.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627?sa-no-redirect=1 https://smile.amazon.com/Growing-Object-Oriented-Software-Gu... https://codeclimate.com/blog/refactoring-without-good-tests/ https://codeclimate.com/blog/refactoring-without-good-tests/

by lowry 8y ago

maxxxxx 8y ago

That's also a problem in medical software. People are so risk averse that they avoid relatively small changes until the whole thing comes crashing down eventually. I have also seen the trend that good developers start to leave and the only people left are low quality developers or outsourcing companies who don't care about what they work on.

lowry 8y ago
Another aspect is the size of the business and the related dilution of power and responsibility. Repaying technical debt in production software means introducing new bugs, instability, change. Users will have to adapt, business KPIs will suffer. The upside won't be visible. No sane middle manager would agree to that, because this will negatively impact his career path. As a solution, I advise organizing work in maintenance teams rather than by project. Having personal responsibility for each feature or process or product also helps.
- maxxxxx 8y ago
  In the end working on large long term projects that a lot of people depend on just is not much fun :). Working on smaller projects where you can make quick changes is much more satisfying.

waterlink 8y ago

> 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.

pmarreck 8y ago

> None is willing to take on the risks associated with technical debt repayment. This risk is vastly mitigated with good test coverage. https://smile.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627?sa-no-redirect=1 https://smile.amazon.com/Growing-Object-Oriented-Software-Gu... https://codeclimate.com/blog/refactoring-without-good-tests/ https://codeclimate.com/blog/refactoring-without-good-tests/