5 ms·

Yes, they are stuck with technical debt which, let's say, they cannot repay. Therefore further development on it is really difficult. This was stated by the de

Yes, they are stuck with technical debt which, let's say, they cannot repay. Therefore further development on it is really difficult. This was stated by the developer in an interview some 5 years ago.

jefftime 9y ago
Do you happen to have a link to that interview? I'd love to read about it
- ebcode 9y ago
  not sure if this is the interview OP is referring to, but the timeframe is right: https://sourceforge.net/blog/potm-201301/ https://sourceforge.net/blog/potm-201301/
deleted 9y ago
[deleted]
bookofjoe 9y ago
What is "technical debt?"
- nurettin 9y ago
  It is a term used by people with hindsight to depict bad decision making in programming that needs a lot of fixing and refactoring later on. And to insinuate they are more cautious.
  - capsulecorp 9y ago
    It doesn't have to be with hindsight, you can forecast technical debt.
    - opcenter 9y ago
      So true. Often technical debt is intentionally taken on as a calculated risk to get to market faster with the intention of fixing it later. Fixing it later rarely happens though. In my experience it either ends up being someone else's problem or you just live with it.
  - psyc 9y ago
    It's very hard to avoid tech debt if you're under constant and severe deadline pressure. But I don't consider it at all hard to avoid otherwise. To me, avoiding debt can be summarized as not taking shortcuts. This shortcut would save time right now, but you know its a hack that makes an abstraction leak? Don't do it. You know an approach is going to cause problems down the line, but you just can't think of a better way? Again, don't do it. See if something comes to mind later. Wrote and tested a bunch of code that seems to work, but there's an itch in the back of your mind saying you haven't thought the problem all the way through? Don't check it in. One might think this sort of approach is paralyzing or something, but in my experience it's extremely empowering over the lifetime of a software project.
    - jimktrains2 9y ago
      You act like you always know what will become debt and even then what will become important debt.
      - psyc 9y ago
        We don’t know much. We have to make calls. What can I say? I’m old and I have my heuristics.
- pmarreck 9y ago
  https://en.wikipedia.org/wiki/Technical_debt https://en.wikipedia.org/wiki/Technical_debt basically it's when a bunch of bad but seemingly-innocuous coding design decisions accumulate and compound each other multiplicatively over time, to the point that any change of the code is far more likely to break something than the new feature is worth Or as I stated at a previous job where I complained about the 40-minute-long test-suite run time that was bogging everyone down, "the road to a 40 minute long test suite is paved with a couple extra seconds here and there with every new code commit"
  - bookofjoe 9y ago
    Clear and to the point for this non-techie: thank you!
  - qwerty456127 9y ago
    Why not just make a conscious decision to stop developing new features and dedicate all the effort to refactoring then?
    - CalvinRodo 9y ago
      That is the solution, but sometimes it's a hard decision to make.
    - khedoros1 9y ago
      A few reasons. If you're an employee building a product for a company, management's always going to push for features, features, features, to keep the customers happy, and to keep up with the competition. Time spent refactoring is an investment in the future, but management tends to be more shortsighted than that. By the time that you really can't add more to the program, it's years down the line, and they've probably been considering pulling the plug anyhow. In my own projects, it's often fun to keep adding things until I hit a roadblock, then spend a couple weeks reworking stuff. It's satisfying to add new features, but architectural maintenance feels like treading water. So, I'd guess that the answer is somewhere between "outside factors dictate that there isn't time" and "we haven't decided to make the time, even though we could". There's an interview with the two main developers here, from 5 years ago: https://sourceforge.net/blog/potm-201301/ https://sourceforge.net/blog/potm-201301/ It sounds like they ran out of energy to really rearchitect the whole thing, or build a new one from scratch.

jefftime 9y ago

Do you happen to have a link to that interview? I'd love to read about it

ebcode 9y ago
not sure if this is the interview OP is referring to, but the timeframe is right: https://sourceforge.net/blog/potm-201301/ https://sourceforge.net/blog/potm-201301/

deleted 9y ago

[deleted]

bookofjoe 9y ago

What is "technical debt?"

nurettin 9y ago
It is a term used by people with hindsight to depict bad decision making in programming that needs a lot of fixing and refactoring later on. And to insinuate they are more cautious.
- capsulecorp 9y ago
  It doesn't have to be with hindsight, you can forecast technical debt.
  - opcenter 9y ago
    So true. Often technical debt is intentionally taken on as a calculated risk to get to market faster with the intention of fixing it later. Fixing it later rarely happens though. In my experience it either ends up being someone else's problem or you just live with it.
- psyc 9y ago
  It's very hard to avoid tech debt if you're under constant and severe deadline pressure. But I don't consider it at all hard to avoid otherwise. To me, avoiding debt can be summarized as not taking shortcuts. This shortcut would save time right now, but you know its a hack that makes an abstraction leak? Don't do it. You know an approach is going to cause problems down the line, but you just can't think of a better way? Again, don't do it. See if something comes to mind later. Wrote and tested a bunch of code that seems to work, but there's an itch in the back of your mind saying you haven't thought the problem all the way through? Don't check it in. One might think this sort of approach is paralyzing or something, but in my experience it's extremely empowering over the lifetime of a software project.
  - jimktrains2 9y ago
    You act like you always know what will become debt and even then what will become important debt.
    - psyc 9y ago
      We don’t know much. We have to make calls. What can I say? I’m old and I have my heuristics.
pmarreck 9y ago
https://en.wikipedia.org/wiki/Technical_debt https://en.wikipedia.org/wiki/Technical_debt basically it's when a bunch of bad but seemingly-innocuous coding design decisions accumulate and compound each other multiplicatively over time, to the point that any change of the code is far more likely to break something than the new feature is worth Or as I stated at a previous job where I complained about the 40-minute-long test-suite run time that was bogging everyone down, "the road to a 40 minute long test suite is paved with a couple extra seconds here and there with every new code commit"
- bookofjoe 9y ago
  Clear and to the point for this non-techie: thank you!
- qwerty456127 9y ago
  Why not just make a conscious decision to stop developing new features and dedicate all the effort to refactoring then?
  - CalvinRodo 9y ago
    That is the solution, but sometimes it's a hard decision to make.
  - khedoros1 9y ago
    A few reasons. If you're an employee building a product for a company, management's always going to push for features, features, features, to keep the customers happy, and to keep up with the competition. Time spent refactoring is an investment in the future, but management tends to be more shortsighted than that. By the time that you really can't add more to the program, it's years down the line, and they've probably been considering pulling the plug anyhow. In my own projects, it's often fun to keep adding things until I hit a roadblock, then spend a couple weeks reworking stuff. It's satisfying to add new features, but architectural maintenance feels like treading water. So, I'd guess that the answer is somewhere between "outside factors dictate that there isn't time" and "we haven't decided to make the time, even though we could". There's an interview with the two main developers here, from 5 years ago: https://sourceforge.net/blog/potm-201301/ https://sourceforge.net/blog/potm-201301/ It sounds like they ran out of energy to really rearchitect the whole thing, or build a new one from scratch.