3 ms·

The tax software situation you're describing sounds totally reasonable, but it does seem indicative of a shortcoming in the market. Like, is there really a fund

The tax software situation you're describing sounds totally reasonable, but it does seem indicative of a shortcoming in the market. Like, is there really a fundamental reason why the same feature set couldn't possibly be developed while also being faster for customers and not requiring more developer resources per feature? In some cases I could see that being the case: if the core task fundamentally requires significant computing resources and margins are too thin to through more resources at it while remaining competitive. That's the "every grocery store has one cashier with a long line" story (except for stores that change the story, e.g. with self checkout or a pricing strategy that frees up some margin to spend on more staff). I wonder how much of the slow performance of tax software is attributable to this, and how much is attributable simply to accumulated bloat or other things that might fall under the vague label "technical debt." But it's also clear that there are technical decisions that can make the software slower for customers without making feature development easier or cheaper or faster.

xyzelement 4y ago
// and how much is attributable simply to accumulated bloat or other things that might fall under the vague label "technical debt." (I am the person you're responding to) - I do think that very often it indeed falls into the vague label of "tech debt" but not all debt needs to be repaid. For example - let's say I am writing a new Turbo Tax feature and I can do it quickly by leveraging 4 existing APIs. My feature is "slow" because each API does its own complex IO operations, many of which are redundant across the 4 calls. Is that technical debt? I have the opportunity to create a new API that optimizes the IO for my use case, and it would be 4x faster. But, it may never be "worth it" to do that because my feature is seldomly used and is still fast enough for the user to not lose productivity. So I would say that's not really a tech debt, just a technical tradeoff that was made. In general, I find that a lot of latency comes from (a) reuse of suboptimal pieces/frameworks that accelerate development and (b) not taking the time to optimize. There are times when these are tech debt, and there are times when these are fine.
- tshaddox 4y ago
  > Is that technical debt? ... So I would say that's not really a tech debt, just a technical tradeoff that was made. Well, I'd still call that technical debt. All debt is a tradeoff, and sometimes debt is worth it (or, at least, is judged to be worth it at the time the debt is taken on). In this case, it might be deemed worth it, and reasonably so, especially if there simply aren't enough competitors that this would make a difference at the margin, or if it's simply not feasible for any competitor to implement that same feature in the same time frame with the same amount of developer resources and make it perform faster.

xyzelement 4y ago

// and how much is attributable simply to accumulated bloat or other things that might fall under the vague label "technical debt." (I am the person you're responding to) - I do think that very often it indeed falls into the vague label of "tech debt" but not all debt needs to be repaid. For example - let's say I am writing a new Turbo Tax feature and I can do it quickly by leveraging 4 existing APIs. My feature is "slow" because each API does its own complex IO operations, many of which are redundant across the 4 calls. Is that technical debt? I have the opportunity to create a new API that optimizes the IO for my use case, and it would be 4x faster. But, it may never be "worth it" to do that because my feature is seldomly used and is still fast enough for the user to not lose productivity. So I would say that's not really a tech debt, just a technical tradeoff that was made. In general, I find that a lot of latency comes from (a) reuse of suboptimal pieces/frameworks that accelerate development and (b) not taking the time to optimize. There are times when these are tech debt, and there are times when these are fine.

tshaddox 4y ago
> Is that technical debt? ... So I would say that's not really a tech debt, just a technical tradeoff that was made. Well, I'd still call that technical debt. All debt is a tradeoff, and sometimes debt is worth it (or, at least, is judged to be worth it at the time the debt is taken on). In this case, it might be deemed worth it, and reasonably so, especially if there simply aren't enough competitors that this would make a difference at the margin, or if it's simply not feasible for any competitor to implement that same feature in the same time frame with the same amount of developer resources and make it perform faster.