4 ms·

A big part of the problem in my opinion, is that people are generally not interested in investing (money, time, effort) in technology. They focus almost exclusi

A big part of the problem in my opinion, is that people are generally not interested in investing (money, time, effort) in technology. They focus almost exclusively on products. The short term is always given a much higher priority than long term. If someone invents a much better way (faster, easier, cheaper) to do some key part of a widely used product (operating system, database, file system, network protocol), they won't get any traction until they have built a competing product with all the bells and whistles around that technology. That can be a formidable task to a startup founder with limited resources who has to try and compete with products that have huge budgets and decades of development behind them. Investors won't touch it until you have a completed and tested product with many customers already signed up. Customers won't touch it until it is a 'drop-in replacement' for their existing solution which requires resources to finish. Classic catch-22 or chicken-and-egg problem. You can't just find a way to do something 10x faster and expect others to flock to it.

sbthrowaway 4y ago
> You can't just find a way to do something 10x faster and expect others to flock to it. I have learned this the hard way. People are generally loss averse and resistant to change so making things better is often an uphill struggle. As an example, I have worked on improving a build tool that is notoriously loathed in part for its poor performance. Part of the problem was that it was a jvm based tool and the jvm has terrible startup performance when loading lots of library code (the tool also made it easy to bring in dependencies so even small projects would often pull in massive amounts of vendor code). The only way to get a reasonably tight feedback loop under those constraints is to run tests in a persistent jvm process that can reuse the loaded classes from prior runs. The difference between using a cached jvm and a fresh jvm could easily be the difference between your tests running in tens of milliseconds or multiple seconds. I produced benchmarks that proved this. But one problem is that any resource leaks in your code or the vendor code will eventually cause the jvm to run out of memory (which often would be a slow process of gradually degrading performance). For this and other reasons, people would often opt out of the in-process test running and fork a fresh jvm with each test run even though it could easily cost them hours of time over the course of a week. The problem was that using the in-process runner required stronger programming discipline. My claim was that code that could reliably run inside of the build tool without resource leaks is more desirable than code that cannot. It is also not particularly more difficult to write, but it does require skill and discipline. There was no tool to statically detect resource leaks so the burden does fall on the individual programmer. It was an exercise in frustration to try and explain the value proposition and argue with people with very different priorities from me so I walked away from the project but to this day it saddens me how much time is being sacrificed to the altar of poor programming discipline.
- szpght 4y ago
  How about starting jvms in advance?
jandrewrogers 4y ago
The positioning heuristic is to never sell a "drop-in replacement", there are myriad reasons that goes poorly. In addition to the problem of feature parity, you also have the extremely painful and expensive implied migration which companies are loathe to do if at all avoidable, you will show up as a threat to the companies you are replacing, possibly with much larger marketing budgets for pushing you out of their market, and you have people whose job is tied to the thing you are replacing quietly sabotaging the deal inside the customer. 10x performance usually won't cover the cost of these issues, in my experience it requires more like 100x performance before the customer calculus starts to swing in your favor. Often you want to position your product to augment their existing systems by addressing a clear gap and nothing more, solving a single serious pain point without actually replacing anything of note. This is simpler and meets less resistance in enterprises, and once inside it becomes much easier to attrit tasks handled by other systems. Land and expand. The challenge for startup founders that want to avoid being a "drop-in replacement" is finding true gaps in the market that are also scalable. Obvious gaps almost always have a reason they are left unfilled.

sbthrowaway 4y ago

> You can't just find a way to do something 10x faster and expect others to flock to it. I have learned this the hard way. People are generally loss averse and resistant to change so making things better is often an uphill struggle. As an example, I have worked on improving a build tool that is notoriously loathed in part for its poor performance. Part of the problem was that it was a jvm based tool and the jvm has terrible startup performance when loading lots of library code (the tool also made it easy to bring in dependencies so even small projects would often pull in massive amounts of vendor code). The only way to get a reasonably tight feedback loop under those constraints is to run tests in a persistent jvm process that can reuse the loaded classes from prior runs. The difference between using a cached jvm and a fresh jvm could easily be the difference between your tests running in tens of milliseconds or multiple seconds. I produced benchmarks that proved this. But one problem is that any resource leaks in your code or the vendor code will eventually cause the jvm to run out of memory (which often would be a slow process of gradually degrading performance). For this and other reasons, people would often opt out of the in-process test running and fork a fresh jvm with each test run even though it could easily cost them hours of time over the course of a week. The problem was that using the in-process runner required stronger programming discipline. My claim was that code that could reliably run inside of the build tool without resource leaks is more desirable than code that cannot. It is also not particularly more difficult to write, but it does require skill and discipline. There was no tool to statically detect resource leaks so the burden does fall on the individual programmer. It was an exercise in frustration to try and explain the value proposition and argue with people with very different priorities from me so I walked away from the project but to this day it saddens me how much time is being sacrificed to the altar of poor programming discipline.

szpght 4y ago
How about starting jvms in advance?

jandrewrogers 4y ago

The positioning heuristic is to never sell a "drop-in replacement", there are myriad reasons that goes poorly. In addition to the problem of feature parity, you also have the extremely painful and expensive implied migration which companies are loathe to do if at all avoidable, you will show up as a threat to the companies you are replacing, possibly with much larger marketing budgets for pushing you out of their market, and you have people whose job is tied to the thing you are replacing quietly sabotaging the deal inside the customer. 10x performance usually won't cover the cost of these issues, in my experience it requires more like 100x performance before the customer calculus starts to swing in your favor. Often you want to position your product to augment their existing systems by addressing a clear gap and nothing more, solving a single serious pain point without actually replacing anything of note. This is simpler and meets less resistance in enterprises, and once inside it becomes much easier to attrit tasks handled by other systems. Land and expand. The challenge for startup founders that want to avoid being a "drop-in replacement" is finding true gaps in the market that are also scalable. Obvious gaps almost always have a reason they are left unfilled.