Yeah but the execution still mattered. I'm a Flash / Shockwave fan as well but there's no point pretending that package was sufficient for the job it was pitched to do. Macromedia seemed to be on a really good track with Shockwave and Flash, but either didn't set up the technology for internet success, or really just sold out the goods with the Adobe acquisition.
In any case, take heart though. If we did it once, we can do it again.
Alright whippersnappers, let's chat about the history of railroads in the US.
In the early 20th century, US rail companies were beholding a very favorable situation: high demand to run loads of heavy freight all over the country, high demand to ferry passengers all over the country, and basically no serious competitors to either revenue source.
Now freight revenue was never going to be transformative to the industry, but it had the benefits of being reliable, un-fussy, and fairly easy to build a financial business around. Passengers, on the other hand, offered huge revenue potential, but had the downsides of being very fussy about things like safety and comfort and timeliness, along with wanting stations in convenient places and an ever-expanding rail network.
Students of US business management history should be unsurprised, then, that while evaluating the market that offered reliable revenue, versus the market that wanted large capital investments, the railroads overwhelmingly chose the freight market. In other words, US the railroad companies spoke and said we do not want passengers loudly and clearly.
The thinking was: passengers can do take the wagons and busses and cars and these newfangled airplane thingies, but freight is a guaranteed market for us! So the passengers slowly migrated to other form of transportation. But the kicker was, freight also wanted things like timeliness and access to an expanding transport network and, shockingly for the railroad execs, were willing to pay for it.
Add about 80 years, declining rail traffic, and tons of corporate mergers, and we have the sad state of US railways today: many residents have never seen a railway expansion or shiny new rail equipment, much less a real functioning passenger train. It's easy and comfortable to say that zoning or regulations or market forces allowed US rail to languish, but that would be ignoring the part where the industry did not want the customers in the first place.
To your first point, yes we're moving slowly towards a more general awareness that most employees are paid market (replacement) rate, not their share of value generated. As the replacement rate drops, so will wages, even if the generated value skyrockets. Unsurprisingly, business owners and upper management love this.
To the second point, the race to the bottom won't be evenly distributed across all markets or market segments. A lot of AI-economy predictions focus on the idea that nothing else will change or be affected by second and third order dynamics, which is never the case with large disruptions. When something that was rare becomes common, something else that was common becomes rare.
The anecdote about the 16-pin religion and the reluctance to use more pins is so good. It's often assumed that (later) successful companies were always making fantastic decisions in the earlier days, when in reality there were a few bizarre and harmful assumptions that were holding it back and needed to be forced out in order for rationality to prevail.
It's the "impact" style of technical write-ups: sell the problem and the scale, then present the solution, which is thus presented and understood through the lens of business and customer success.
Generously, this writing style is supposed to show the business value of teams and individuals, for promotions or other recognition. But yeah, it can be frustrating to read this style.
Oh lordy, the "two crews" bifurcation fully written down. What a fantastic way to ship until it becomes far too expensive to ship anything good.
Look, when we break the feedback loop back to the people who wrote the software in the first place, they get happier for a bit, you make some other people sadder for a bit, and then slowly your feature crew never want to be interrupted or bothered again and your customer crew can't get enough resources to fully fix anything.
Worse, your feature crews aren't learning anything beyond how to get those lines out the door, which will somehow get slower and more expensive as time goes on. Why? Because you removed the one fitness function on good software development which is to fully re-incorporate the negative feedback back into the source of development.
A real CTO leadership handbook would say clearly "it's your responsibility to help your developers improve, especially while shipping, and they're not always going to be happy about it."
Because a lot of tech workers today aren't actually job hopping and instead get very cozy in a job and a team and a career trajectory, which feels unfairly ripped away during layoffs for reasons that don't feel connected to their personal performance.
I often see rate limits framed as a way to protect system capacity, but not enough follow-through with understanding why, even with appropriate rate limits, systems can fall over and require manual intervention to restore.
The easiest way to explain this is with a simple sequence of events: the database has a temporary issue, system capacity drops, clients start timing out or getting errors, load amplification kicks in with retries and request queueing, load is now higher than normal while capacity is lower than normal, devs work hard to get the database back in order, database looks restored but now the system has 3x the load it did before the incident, other heroic efforts are needed to shed load and/or upscale capacity, whew it's all working again! In the post-mortem there are lots of questions about why rate-limiting didn't protect the system. Unfortunately, the rate limit values required to restore the saturated system are far too low for normal usage, and the values needed for normal operation are too high to prevent the system from getting saturated.
Fundamentally, there's really no way for a rate limiting (which only understands incoming load) to balance the equation load <= capacity. For that, we need a back-pressure mechanism like circuit breaking, concurrency limiting, or adaptive request queueing. Fortunately, rate limiting and back-pressure work well together and don't have to know about each other.
A few of extra considerations picked up over many years of hard lessons:
1. Rate limits don't really protect against backend capacity issues, especially if they are statically configured. Consider rate limits to be "policy" limits, meaning the policy of usage will be enforced, rather than protection against overuse of limited backend resources.
2. If the goal is to protect against bad traffic, consider additional steps besides simple rate limits. It may make sense to perform some sort of traffic prioritization based on authentication status, user/session priority, customer priority, etc. This comes in handy if you have a bad actor!
3. Be prepared for what to communicate or what action(s) to perform if and when the rate limits are hit, particularly from valuable customers or internal teams. Rate limits that will be lifted when someone complains might as well be advisory-only and not actually return a 429.
4. If you need to protect against concertina effects (all fixed windows, or many sliding windows expiring at the same time), add a deterministic offset to each user/session window so that no large group of rate limits can expire at the same time.
In any case, take heart though. If we did it once, we can do it again.