19 ms·

Those are rookie numbers. With a little Kubernetes, we can get them way up. So much of the incentive structure in software companies is to ship new features. M

Those are rookie numbers. With a little Kubernetes, we can get them way up. So much of the incentive structure in software companies is to ship new features. Maintaining existing ones or fixing bugs is a career dead end for software engineers and managers. No wonder so much stuff is broken and slow. Call me cynical, but from a dollars point of view this seems to be what customers want.

hifromLA 3y ago
I do agree when we see broken outcomes (e.g. us healthcare, us public transit, etc) it’s good to go back to incentives to understand why things haven’t gotten better. When perf time comes around, everybody knows the deal. Shipping a new feature is a much easier sell than a bug fix and looking like a hero for fixing a bug instead of preventing one is easier anyways.
IshKebab 3y ago
I agree. I have to really fight people when I try to write robust software. "Why are you writing a proper parser when a hacky regex that I thought about for 2 seconds worked the one time I tested it? You're wasting time." They don't understand that I'm not wasting time, I'm just choosing to spend a little bit of time earlier, because I don't like spending a lot of time later when debugging why everything broke.
- datavirtue 3y ago
  Same here. I stopped suggesting robustness because no one cares.
  - ilyt 3y ago
    I just include writing robust code in my estimates and don't tell anyone. Shoddy code only happens in "the production is on actual fire, not manager-imagined fire" fixes and not for long.
- sempron64 3y ago
  The problem with a careful but non-methodical approach is that it requires the programmer to correctly determine the stability value of their design. We often overestimate the importance of architecture on stability, or worse, architect something that is harder to maintain than the naive solution. With buggy ship-it-now software you have a known bounded risk - bugs will occur in some cases but the software will ship and the bugs can be fixed because it’s simple. With prematurely architected software the risk is unbounded - the project may get bogged down indefinitely in its own complexity without shipping. The inverse extreme can also be a problem, of course A project that is maintained for a long time on the naive implementation will also become unmaintainable. However, this will be due to _known_ architecture problems encountered during maintenance. These problems can be addressed in a relatively bounded amount of time. They are also quantifiable and thus explainable to management.
  - im_down_w_otp 3y ago
    The specific case of building a proper parser doesn't take that much longer if you know what you're doing, and it also enables lots of wonderful quality of life features for end users through additional opportunities for automation and contextualization that can be surfaced. Though, given the constant incentive to never learn how to write a proper parser does mean that practically nobody knows how to do it, and so it will always look & feel like an unbounded science project, and thus rarely done. Infinitely recursive MVP'ing is a race to the bottom.
    - sempron64 3y ago
      Particularly regarding parsing: Here's an excerpt from an interview with Anders Hjelsberg I heard recently. He's the creator of the Turbo Pascal compiler and later on of the creators of C#. https://www.aarthiandsriram.com/p/our-dream-conversation-anders-hejlsberg https://www.aarthiandsriram.com/p/our-dream-conversation-and... ``` Turbo Pascal 2 and Hash Tables Sriram: I think there is some, we're going to talk later about things like GitHub co-pilot, we're dealing with different kinds of code reuse, but I do think there's a little bit of romance in the, for example, I idol you and folks like John Carmack. John Carmack noodling away and trying to make sure every instruction and memory access is aligned on some cash line. The amazing thing is, even today, if you look at AI at the heart of it, you have matrix multiplication and doing things with floating point numbers. Some of these things really tend to matter, which on the theme of optimization, tell us a story of Turbo Pascal 2 and you discovering hash tables because it's legendary. Anders: [laughs] It is a funny story. You have to remember here that I am self-taught in the art of writing compilers. Now, I have since discovered and read a lot of the literature, but at the time, I was just coding away and doing it the best way I knew how. When you create a compiler, one of the things you have to create is simple tables, or they're not necessarily tables. They could be linked list, they could be whatever, but you have to look up names. When you're trying to compile a code that tries to assign one to X, well, you have to figure out where is X? What memory address have I associated with X? You have to look it up the declaration of X. In Turbo Pascal 1.0, the first version of Turbo Pascal, all of the variable declarations were just kept on a linked list because that much I knew, but of course, searching linked lists is not particularly efficient when they get large. For really large functions, that would just take an awfully long time. Then, well, maybe you could try first go by first letter, and then have 26 linked lists or whatever, and that could help a little bit. Then I remember reading the literature about these things called hash tables actually in this book by Niklaus Wirth, Algorithms +, what is it? Yes, Algorithms + Data Structures = Programs. A great book. He explains hash tables and I go, "Oh my God, that's amazing. I got to go try this." I went and implemented it and boom, the compiler went twice as fast. There's Turbo Pascal version 2.0. [laughter] Aarthi: Awesome. Anders: There's a good reason to sell upgrades. ``` Do you really need a proper parser to sell 1.0? A literal compiler project did not fail due to the lack of a "proper" parser (though it can be argued that the lookup table is after the parsing stage; obviously there was not a strong distinction in the Turbo Pascal implementation between tokenization and compilation).
- yodsanklai 3y ago
  Nowadays, I'm maximizing my salary, and the way to do that is please management by shipping features. There's no incentive to add tests or refactor code, and I'm not going to win this battle. That being said, over the years I've learned to appreciate the point for shipping fast. Sometimes it's the right thing to do, it's always a tradeoff.
sublinear 3y ago
> So much of the incentive structure in software companies is to ship new features. Maintaining existing ones or fixing bugs is a career dead end Highly dependent on where you work and what you consider a "dead end". You can't possibly be talking about becoming unemployable in the industry nor even a pay cut. The situation for senior devs is the opposite, actually. Maintenance is the long tail of every project. If you're not doing that, you're not really working in software.
javajosh 3y ago
There is something like a paradox of automation at play, too. Both business and programmers are aligned on not wanting drudgery, but this means that a) we undervalue first-order work, and b) our automation reach often exceeds our grasp (k8s being an excellent example). Perhaps my thinking is colored by my recent read of Patrick O'Brian's excellent "Master and Commander" series of historical novels, about early 18th century English sailing ships, but the lack of automation is part of the romance - just to get from "here" to "there" required enormous effort. And who knows? Maybe if we take that approach we can press people into the software service by force, just like in the good old days!
- ElectricalUnion 3y ago
  > about early 18th century English sailing ships, but the lack of automation is part of the romance The highly hierarchical and structured command structure of a ship means that autonomous and intelligent human beings each make autonomous and intelligent decisions on the best course of action in a way that doesn't require constant and immediate upper layer attention all the time. The more limited amount of human beings required to upkeep a ship those days are mainly because of manpower shortage and cost reasons, not because the removed humans were "worse" at doing such operations. Those automation flows are in my opinion the same thing, they're replacing things because of manpower shortages or high costs of the previous thing, not because they're better.
- javajosh 3y ago
  Correction: late 18th and early 19th century sailing ships.
wredue 3y ago
Dude on HN was describing the other day how they’re moving to use an AI to generate a list of cars with specific features in their inventory and how this was a great part of the AI future. But as we see frequently even on the most sophisticated AIs, they get shit wrong… a lot. So this company decided to replace an actually working, guaranteed to produce proper results filtering system with a guaranteed to not produce proper results an unknown amount of the time, and the feeling was that this was good business direction. People want buzzwords, not working software.
- nerdponx 3y ago
  People don't want buzzwords, people want promotions, bonuses, and recognition. It turns out that producing working software is not the optimal way to obtain those things at a lot of companies.
  - A4ET8a8uTh0 3y ago
    And how do you get said promotions, bonuses and recognition? By introducing change. And what change is easiest? One that relies on established ground of buzzwords.
    - gAI 3y ago
      I'm detecting a lack of synergy here.
      - hinkley 3y ago
        We haven't leveraged those for at least ten years.
        fsckboy 3y ago
        careful who you make fun of, technical debt is technically leverage
      - iso1631 3y ago
WinLychee 3y ago
Not just new features, but making everything way more complicated too!
q845712 3y ago
I'm not sure it's exactly "what customers want" so much as it is the sweet-spot or intersection of the two curves: "what customers want" with "how much cost and risk owners and managers are willing to put in up front"
- sixstringtheory 3y ago
  My thoughts too. With VC-funded freemium models, I think it’s hard to make a clear case for who the paying customer is and what they want.
ravenstine 3y ago
Add on top of that the perception that users need "wow" factor for everything. We can't ever have a full page refresh, even for something as simple as a blog or a storefront, despite most users being oblivious to when those take place. Everything's got to be flashy and overly designed. If it doesn't look like The Google designed it, then no one will use it!!! /s
MattGaiser 3y ago
> but from a dollars point of view this seems to be what customers want. What percentage of software (in dollars) is purchased by people who are not going to be the ones using it? I suspect the answer is the overwhelming majority. It is how software monstrosities like Concur can exist and be ubiquitous.
npsimons 3y ago
> Call me cynical, but from a dollars point of view this seems to be what customers want. I'm right there with you, except I don't give "customers" that much credit. Most people left to their own devices (ie, not brainwashed by marketing) will just stick with "good enough." But it's less fun (and less profitable) to fix and maintain old code, so companies induce "demand" by marketing. And if you're a company who decides to do the adult thing and not play that game, you'll be creamed by the ones that do.
coderintherye 3y ago
>Maintaining existing ones or fixing bugs is a career dead end for software engineers and managers Strong disagree. This may be the case at certain "tech" companies, but I grew my career into CTO through maintaining existing systems and fixing bugs (and through doing the things no one else wanted to do). Amongst my fellow members of the particular CTO club I'm in, I'd say about 1/4 to 1/3rd followed a similar path. There is a related way you can limit your career though, by becoming an expert on a non-critical system and limiting your focus solely to it. Many engineers take that path because it feels safe and offers job security, but it will limit upward mobility options.
wouldbecouldbe 3y ago
Haha yeah. Kubernetes on Azure for bonus points. Not only do you waste more time, you also pay more and are recommended to get an expensive certificate.
jonhohle 3y ago
Maybe that’s a good business idea: solely focus on bug fixes for clients so their “rockstars” can architect their way into more bugs that need fixing. Since the business’s employees I are only focused on bugs, and not features, they’re not leaving tech debt in their wake.
- febusravenga 3y ago
  it's my strategy since I become bored with tech. I don't have passion or urge to create new useless software. There are many young or naive or plainly stupid which do. But I still have skills and insight to cover their asses when they corner themselves and are too busy with next fad and there are bugs to be fixed in yesterday's crapware... and I'm only 40..
Tade0 3y ago
> Those are rookie numbers. With a little Kubernetes, we can get them way up. I used to be a frontend developer, but now my problems include `Error: mkdir /bitnami/postgresql/data: permission denied`. All I wanted was to have a Persistent Volume Claim on my Postgres container that is part of a new dev environment I'm setting up. The other one worked, and still works fine.
mattpallissard 3y ago
> Those are rookie numbers. I make a living dealing with computer problems.
happymellon 3y ago
Fucking hell, I've just blown another day because I'm dealing with over engineered crap. We are on AWS, and a Postgres database that is primarily in one region, and read only in a second? That should be Aurora, and 15 lines of CloudFormation/CDK/whatever. But that's too easy and reliable, who would need an SRE and an architect then? Instead we have multiple RDS instances, and a regularly failing PG Logical installation which requires an engineer constantly checking in on it because it silently fails and you only find out when storage starts burning out fast. There is no feedback loop to let leadership know that they are spending hundreds of thousands over the odds for an unreliable system, and architects who seem to fail to admit someone made a misjudged call a couple of years ago. I don't know what the solution is, but currently it's just some shitty old boys club. Yes, they also picked Kubernetes but decided to install their own instance on AWS. Why the hell are we in a managed eco system and trying to build it in the worst way possible? Everything crashes on a regular basis.
bobthepanda 3y ago
At least over half the issues sound like issues with computer hardware/OS (the computer froze/the wheel keeps spinning) Many people have tried to have an OS and pretty much all except MS, Apple and Google have failed at the consumer level.
ilyt 3y ago
Just today we had a call with devs that wanted to run k8s (managed by us) on client's stuff (when we generally got few VMs and cranky security guys any time we needed some traffic passed thru). To run app that's like 3 containers with services, a queue, and a database. Took a second to explain that overhead, added management, and sheer paperwork to run it on client's infrastructure is absolutely not worth saving them like... a day or two making a bit more complex deploy script.
yodelshady 3y ago
I've spent the last two days working with (not-Kubernetes) virtualisation software that has serious, workflow-breaking bugs from... uploading and removing regular files, of a format it expects. In some random-aaS frontend I could expect that, but this is systems stuff. :(.
nick-of-time 3y ago
> Call me cynical, but from a dollars point of view this seems to be what customers want. Since when have the wants of customers been the driving factor behind business decisions? There is a downstream effect, sure, as long as there is competition, but businesses are controlled by petty little weirdos with short attention spans like Elon Musk. Does this make me more or less cynical than you?

hifromLA 3y ago

I do agree when we see broken outcomes (e.g. us healthcare, us public transit, etc) it’s good to go back to incentives to understand why things haven’t gotten better. When perf time comes around, everybody knows the deal. Shipping a new feature is a much easier sell than a bug fix and looking like a hero for fixing a bug instead of preventing one is easier anyways.

IshKebab 3y ago

I agree. I have to really fight people when I try to write robust software. "Why are you writing a proper parser when a hacky regex that I thought about for 2 seconds worked the one time I tested it? You're wasting time." They don't understand that I'm not wasting time, I'm just choosing to spend a little bit of time earlier, because I don't like spending a lot of time later when debugging why everything broke.

datavirtue 3y ago
Same here. I stopped suggesting robustness because no one cares.
- ilyt 3y ago
  I just include writing robust code in my estimates and don't tell anyone. Shoddy code only happens in "the production is on actual fire, not manager-imagined fire" fixes and not for long.
sempron64 3y ago
The problem with a careful but non-methodical approach is that it requires the programmer to correctly determine the stability value of their design. We often overestimate the importance of architecture on stability, or worse, architect something that is harder to maintain than the naive solution. With buggy ship-it-now software you have a known bounded risk - bugs will occur in some cases but the software will ship and the bugs can be fixed because it’s simple. With prematurely architected software the risk is unbounded - the project may get bogged down indefinitely in its own complexity without shipping. The inverse extreme can also be a problem, of course A project that is maintained for a long time on the naive implementation will also become unmaintainable. However, this will be due to _known_ architecture problems encountered during maintenance. These problems can be addressed in a relatively bounded amount of time. They are also quantifiable and thus explainable to management.
- im_down_w_otp 3y ago
  The specific case of building a proper parser doesn't take that much longer if you know what you're doing, and it also enables lots of wonderful quality of life features for end users through additional opportunities for automation and contextualization that can be surfaced. Though, given the constant incentive to never learn how to write a proper parser does mean that practically nobody knows how to do it, and so it will always look & feel like an unbounded science project, and thus rarely done. Infinitely recursive MVP'ing is a race to the bottom.
  - sempron64 3y ago
    Particularly regarding parsing: Here's an excerpt from an interview with Anders Hjelsberg I heard recently. He's the creator of the Turbo Pascal compiler and later on of the creators of C#. https://www.aarthiandsriram.com/p/our-dream-conversation-anders-hejlsberg https://www.aarthiandsriram.com/p/our-dream-conversation-and... ``` Turbo Pascal 2 and Hash Tables Sriram: I think there is some, we're going to talk later about things like GitHub co-pilot, we're dealing with different kinds of code reuse, but I do think there's a little bit of romance in the, for example, I idol you and folks like John Carmack. John Carmack noodling away and trying to make sure every instruction and memory access is aligned on some cash line. The amazing thing is, even today, if you look at AI at the heart of it, you have matrix multiplication and doing things with floating point numbers. Some of these things really tend to matter, which on the theme of optimization, tell us a story of Turbo Pascal 2 and you discovering hash tables because it's legendary. Anders: [laughs] It is a funny story. You have to remember here that I am self-taught in the art of writing compilers. Now, I have since discovered and read a lot of the literature, but at the time, I was just coding away and doing it the best way I knew how. When you create a compiler, one of the things you have to create is simple tables, or they're not necessarily tables. They could be linked list, they could be whatever, but you have to look up names. When you're trying to compile a code that tries to assign one to X, well, you have to figure out where is X? What memory address have I associated with X? You have to look it up the declaration of X. In Turbo Pascal 1.0, the first version of Turbo Pascal, all of the variable declarations were just kept on a linked list because that much I knew, but of course, searching linked lists is not particularly efficient when they get large. For really large functions, that would just take an awfully long time. Then, well, maybe you could try first go by first letter, and then have 26 linked lists or whatever, and that could help a little bit. Then I remember reading the literature about these things called hash tables actually in this book by Niklaus Wirth, Algorithms +, what is it? Yes, Algorithms + Data Structures = Programs. A great book. He explains hash tables and I go, "Oh my God, that's amazing. I got to go try this." I went and implemented it and boom, the compiler went twice as fast. There's Turbo Pascal version 2.0. [laughter] Aarthi: Awesome. Anders: There's a good reason to sell upgrades. ``` Do you really need a proper parser to sell 1.0? A literal compiler project did not fail due to the lack of a "proper" parser (though it can be argued that the lookup table is after the parsing stage; obviously there was not a strong distinction in the Turbo Pascal implementation between tokenization and compilation).
yodsanklai 3y ago
Nowadays, I'm maximizing my salary, and the way to do that is please management by shipping features. There's no incentive to add tests or refactor code, and I'm not going to win this battle. That being said, over the years I've learned to appreciate the point for shipping fast. Sometimes it's the right thing to do, it's always a tradeoff.

sublinear 3y ago

> So much of the incentive structure in software companies is to ship new features. Maintaining existing ones or fixing bugs is a career dead end Highly dependent on where you work and what you consider a "dead end". You can't possibly be talking about becoming unemployable in the industry nor even a pay cut. The situation for senior devs is the opposite, actually. Maintenance is the long tail of every project. If you're not doing that, you're not really working in software.

javajosh 3y ago

There is something like a paradox of automation at play, too. Both business and programmers are aligned on not wanting drudgery, but this means that a) we undervalue first-order work, and b) our automation reach often exceeds our grasp (k8s being an excellent example). Perhaps my thinking is colored by my recent read of Patrick O'Brian's excellent "Master and Commander" series of historical novels, about early 18th century English sailing ships, but the lack of automation is part of the romance - just to get from "here" to "there" required enormous effort. And who knows? Maybe if we take that approach we can press people into the software service by force, just like in the good old days!

ElectricalUnion 3y ago
> about early 18th century English sailing ships, but the lack of automation is part of the romance The highly hierarchical and structured command structure of a ship means that autonomous and intelligent human beings each make autonomous and intelligent decisions on the best course of action in a way that doesn't require constant and immediate upper layer attention all the time. The more limited amount of human beings required to upkeep a ship those days are mainly because of manpower shortage and cost reasons, not because the removed humans were "worse" at doing such operations. Those automation flows are in my opinion the same thing, they're replacing things because of manpower shortages or high costs of the previous thing, not because they're better.
javajosh 3y ago
Correction: late 18th and early 19th century sailing ships.

wredue 3y ago

Dude on HN was describing the other day how they’re moving to use an AI to generate a list of cars with specific features in their inventory and how this was a great part of the AI future. But as we see frequently even on the most sophisticated AIs, they get shit wrong… a lot. So this company decided to replace an actually working, guaranteed to produce proper results filtering system with a guaranteed to not produce proper results an unknown amount of the time, and the feeling was that this was good business direction. People want buzzwords, not working software.

nerdponx 3y ago
People don't want buzzwords, people want promotions, bonuses, and recognition. It turns out that producing working software is not the optimal way to obtain those things at a lot of companies.
- A4ET8a8uTh0 3y ago
  And how do you get said promotions, bonuses and recognition? By introducing change. And what change is easiest? One that relies on established ground of buzzwords.
  - gAI 3y ago
    I'm detecting a lack of synergy here.
    - hinkley 3y ago
      We haven't leveraged those for at least ten years.
      - fsckboy 3y ago
        careful who you make fun of, technical debt is technically leverage
    - iso1631 3y ago

WinLychee 3y ago

Not just new features, but making everything way more complicated too!

q845712 3y ago

I'm not sure it's exactly "what customers want" so much as it is the sweet-spot or intersection of the two curves: "what customers want" with "how much cost and risk owners and managers are willing to put in up front"

sixstringtheory 3y ago
My thoughts too. With VC-funded freemium models, I think it’s hard to make a clear case for who the paying customer is and what they want.

ravenstine 3y ago

Add on top of that the perception that users need "wow" factor for everything. We can't ever have a full page refresh, even for something as simple as a blog or a storefront, despite most users being oblivious to when those take place. Everything's got to be flashy and overly designed. If it doesn't look like The Google designed it, then no one will use it!!! /s

MattGaiser 3y ago

> but from a dollars point of view this seems to be what customers want. What percentage of software (in dollars) is purchased by people who are not going to be the ones using it? I suspect the answer is the overwhelming majority. It is how software monstrosities like Concur can exist and be ubiquitous.

npsimons 3y ago

> Call me cynical, but from a dollars point of view this seems to be what customers want. I'm right there with you, except I don't give "customers" that much credit. Most people left to their own devices (ie, not brainwashed by marketing) will just stick with "good enough." But it's less fun (and less profitable) to fix and maintain old code, so companies induce "demand" by marketing. And if you're a company who decides to do the adult thing and not play that game, you'll be creamed by the ones that do.

coderintherye 3y ago

>Maintaining existing ones or fixing bugs is a career dead end for software engineers and managers Strong disagree. This may be the case at certain "tech" companies, but I grew my career into CTO through maintaining existing systems and fixing bugs (and through doing the things no one else wanted to do). Amongst my fellow members of the particular CTO club I'm in, I'd say about 1/4 to 1/3rd followed a similar path. There is a related way you can limit your career though, by becoming an expert on a non-critical system and limiting your focus solely to it. Many engineers take that path because it feels safe and offers job security, but it will limit upward mobility options.

wouldbecouldbe 3y ago

Haha yeah. Kubernetes on Azure for bonus points. Not only do you waste more time, you also pay more and are recommended to get an expensive certificate.

jonhohle 3y ago

Maybe that’s a good business idea: solely focus on bug fixes for clients so their “rockstars” can architect their way into more bugs that need fixing. Since the business’s employees I are only focused on bugs, and not features, they’re not leaving tech debt in their wake.

febusravenga 3y ago
it's my strategy since I become bored with tech. I don't have passion or urge to create new useless software. There are many young or naive or plainly stupid which do. But I still have skills and insight to cover their asses when they corner themselves and are too busy with next fad and there are bugs to be fixed in yesterday's crapware... and I'm only 40..

Tade0 3y ago

> Those are rookie numbers. With a little Kubernetes, we can get them way up. I used to be a frontend developer, but now my problems include `Error: mkdir /bitnami/postgresql/data: permission denied`. All I wanted was to have a Persistent Volume Claim on my Postgres container that is part of a new dev environment I'm setting up. The other one worked, and still works fine.

mattpallissard 3y ago

> Those are rookie numbers. I make a living dealing with computer problems.

happymellon 3y ago

Fucking hell, I've just blown another day because I'm dealing with over engineered crap. We are on AWS, and a Postgres database that is primarily in one region, and read only in a second? That should be Aurora, and 15 lines of CloudFormation/CDK/whatever. But that's too easy and reliable, who would need an SRE and an architect then? Instead we have multiple RDS instances, and a regularly failing PG Logical installation which requires an engineer constantly checking in on it because it silently fails and you only find out when storage starts burning out fast. There is no feedback loop to let leadership know that they are spending hundreds of thousands over the odds for an unreliable system, and architects who seem to fail to admit someone made a misjudged call a couple of years ago. I don't know what the solution is, but currently it's just some shitty old boys club. Yes, they also picked Kubernetes but decided to install their own instance on AWS. Why the hell are we in a managed eco system and trying to build it in the worst way possible? Everything crashes on a regular basis.

bobthepanda 3y ago

At least over half the issues sound like issues with computer hardware/OS (the computer froze/the wheel keeps spinning) Many people have tried to have an OS and pretty much all except MS, Apple and Google have failed at the consumer level.

ilyt 3y ago

Just today we had a call with devs that wanted to run k8s (managed by us) on client's stuff (when we generally got few VMs and cranky security guys any time we needed some traffic passed thru). To run app that's like 3 containers with services, a queue, and a database. Took a second to explain that overhead, added management, and sheer paperwork to run it on client's infrastructure is absolutely not worth saving them like... a day or two making a bit more complex deploy script.

yodelshady 3y ago

I've spent the last two days working with (not-Kubernetes) virtualisation software that has serious, workflow-breaking bugs from... uploading and removing regular files, of a format it expects. In some random-aaS frontend I could expect that, but this is systems stuff. :(.

nick-of-time 3y ago

> Call me cynical, but from a dollars point of view this seems to be what customers want. Since when have the wants of customers been the driving factor behind business decisions? There is a downstream effect, sure, as long as there is competition, but businesses are controlled by petty little weirdos with short attention spans like Elon Musk. Does this make me more or less cynical than you?