Comment by scott_w
4 months ago
So you're kinda falling into a fallacy here. You're taking a specific example and trying to make a general rule out of it. I also think the author of the article is doing the same thing, just in a different way.
Users don't care about the specifics of your tech stack (except when they do) but they do care about whether it solves their problem today and in the future. So they indirectly care about your tech stack. So, in the example you provided, the user cares about performance (I assume Rippling know their customer). In other examples, if your tech stack is stopping you from easily shipping new features, then your customer doesn't care about the tech debt. They do care, however, that you haven't given them any meaningful new value in 6 months but your competitor has.
I recall an internal project where a team discussed switching a Python service with Go. They wanted to benchmark the two to see if there was a performance difference. I suggested from outside that they should just see if the Python service was hitting the required performance goals. If so, why waste time benchmarking another language? It wasn't my team, so I think they went ahead with it anyway.
> You're taking a specific example and trying to make a general rule out of it.
I used a specific example to disprove a straw men about the impact of tech choices on latency. Then I brought up a second personal example (e-commerce sites) and data from a large e-commerce site (impact of latency) to illustrate that latency could drive a direct business loss (and be very hard to measure).
> I recall an internal project where a team discussed switching a Python service with Go.
Picking an initial choice and switching a choice are very different problems. The latter has an inherent large cost.