And one of the puzzling things to me here is what all those engineers are doing. I mean, if you're making bad hiring decisions, engineers can happily create work for one another and themselves, so I get where the labor could be going. But it does not look to me like Lyft and Uber are particularly feature-filled.
I suspect that if rideshare companies ever get to being profitable, we'll see the emergence of white-label rideshare software that gets made for a tiny fraction of the cost of what Lyft and Uber spend. Because that'll be an organization with a real incentive to keep costs down.
Thanks, I hadn't seen that. And yes, nobody should get into that game until prices stabilize such that the rideshare companies are profitable. When the game is setting money on fire in pursuit of a monopoly, you can't compete with Uber.
As always with large companies, what you see as a consumer is only the tip of the iceberg. For every user-facing line of code you have a hundred or a thousand lines of code made internal-only services, for interacting with partners, for variations due to local restrictions, etc.
Sure. I mean I have some questions about your proportions, but let that pass. We clearly agree that the amount of total code is proportional to the user-facing stuff. Which for Lyft seems to be quite stable. And since the main function of developers is to improve things, that makes me wonder.
I also suspect that with larger companies, a lot of that below-the-waterline code is not ultimately necessary, the kind of stuff that if they were running a tight ship wouldn't be there. I certainly get reports like that from friends, anyhow. But it sounds like that's ultimately not an engineering problem but a management problem.
I suspect that if rideshare companies ever get to being profitable, we'll see the emergence of white-label rideshare software that gets made for a tiny fraction of the cost of what Lyft and Uber spend. Because that'll be an organization with a real incentive to keep costs down.