For the Van Ness Bus Line example: one reason there were major delays was because maps of underground sewer lines and plumbing were inaccurate, and needed to be relocated. The 6 years of construction was really a bus lane + major sewer infrastructure project.
Which brings up another reason why some of these projects were Fast -- they operated in places where there there wasn't existing infrastructure or residents to deal with, or cut corners on planning and mapping, which future projects now have to deal with.
Immediately after breaking ground, construction delays began. Existing maps of old gas, water and sewer lines flowing beneath the center of Van Ness Avenue proved inaccurate, slowing excavation and causing the city to bring in utility contractors. The utility placement also made the BRT’s center-lane design a challenge: Any future sewer and water repairs would disable bussing for the duration of repair. Plus, overhead bus electrical wires would need to be fully removed for the safety of the crews. Water and sewer infrastructure needed to be moved to the outside lanes to keep the center-lane BRT design — deemed the best for traffic flow.
One of the big reasons, was that regulatory hurdles were removed.
The result:
Long Island is one big Superfund site, and our cancer rates are through the roof. I know of at least six women, in my immediate orbit, that are currently being, or have recently been, treated for breast cancer.
Before I moved here, thirty-two years ago, I had never met anyone that had cancer. Since moving here, I have known at least one person per year (often more), that had/have cancer.
Part of that is probably age, as I've gotten older, so too, has my peer group, but I wasn't that old, in 1990, when I moved here.
The difference is that they died a lot more frequently, back then.
Just want to mention this because this parable gets thrown around a lot.
The delta between what git is now and what it was when first released is massive. Junio Hamano has been a absolute force of a maintainer and steward over the interim 18 years (!!) since 2005.
This story often gets tossed around, as if to imply all of what git is today was put out by Linus in 2 weeks, but I think it suffers from a bit of a hero worship problem. It was no doubt impressive and should be recognized, but I just want to make it clear: Git was made by many people over many years.
I think that’s mostly understood. It’s up there with “JS was implemented in a week.” Yet in both cases, the skeleton defined the rest of the animal; git and JS are still recognizable from that initial version, even if the diff is massive.
Maintainers should get more credit, but the hero worship isn’t entirely misplaced. It’s not often that someone gets to change the world.
I was the original author of multiple systems that have lasted decades, but I'll bet that you'd be hard-pressed to find much of my original code, in the current iterations.
> But Git was initially written by one cranky Finn, in ten days. It totally changed the way we all work.
To be fair, Linus was trying to replace Bitkeeper, a proprietary DVCS which he'd been using to maintain the kernel for several years at that point. Mercurial, which runs on similar principles, was around at the time too. He didn't just make a quantum conceptual leap straight from SVM to git on his own in 10 days; he had a pretty good idea what he wanted to build (probably even ideas about the architecture) before he started.
It's still darned impressive; just not supernaturally impressive. :-)
I see this as kinda the flipside of "how to draw an owl" [1]. A smarter programmer than me once described software as "do 90%, then do the other 90%" - the mvp, first functional prototype, heck, even the first deliverable is great and all, but then it's time for the thing to live and breathe and go out in the real world and learn all about what it'll become someday. Thus was born semantic versioning.
On the other end of that, like what you're talking about, you have the artist who answers "how long did it take you to paint that?" with: "my whole life". I think this holds true in most disciplines and especially in software. The actual code that makes a thing work is trivial - but you have to know which of the 9 gazillion ways of doing it is the one you want, which only comes from experience.
I've also read that Linus was pretty influential in BitKeeper design too. As in Larry McVoy would sit down with Linus to talk about the design of it. Git's core data structures had probably been bouncing around in Linus's head for months before first line of code was written.
If you know both BitKeeper and Git internals, you can think of their data models as near identical, with BitKeeper implementation using text files and SCCS, and Git using from-scratch data structures.
JS on the list is quite interesting, since it being rushed and a prototype ending up getting shipped often gets cited as an explanation for why JS has issues. Given how widespread it is, this is a project I wish had gotten a lot more time. An argument could be made that it succeeded, so it must be good, but given it's the only built-in, full language in the browser just says that it was good enough and now we are kinda stuck with it.
Good thing we ended up with a small language that has easy objects, first-class functions, and compact syntax. We could have got something like ABAP were we really unlucky.
As much as I couldn't live without complaining about Javascript's shortcomings, I have to agree with this. At the time, many of the features you mention were hardly necessary - no one was considering using it to build giant web apps, let alone servers! The fact that people decided they could do those things and the language was sufficiently flexible to grow along those lines would probably be very surprising to the original developer. For having such a chaotic evolution, it's becoming a much better language than anyone would have a right to expect.
Kind of like English, which is also a terrible choice for a global language, it's shown a fairly powerful ability to incorporate new idioms.
I don't believe this. Someone who knows how to design and implement a language with real closures, prototype-based inheritance, a garbage collector, etc. also knows the value and power of those things, used them before extensively and knows how far they can go. Also, the shortcomings that everybody loves to talk about are mostly misunderstood features (yes, even == which everybody loves to hate), and mostly by programmers who wouldn't even know where to start designing a language.
Most of the inconsistencies, like "checkout" having three different functions, were added much later, in attempts to make UX niftier locally, without thinking about the product as a whole.
For what it’s worth, this is now being separated out a bit to be clearer. You can use `git switch <branch>` to switch to an existing branch, `git switch --create <branch>` to create a new branch and switch to it, and `git restore <file>` or `git restore --source <ref> file` to restore a version of a file to your working directory.
Eh, I can squint and see that as a special-case of moving your head to another ref - the `-b` merely flagging "if this branch doesn't exist, create it instead of erroring".
I can't comment on the bus line example, but the New York Times had a great write-up (https://www.nytimes.com/2017/12/28/nyregion/new-york-subway-...) about subway building in New York. At least in New York there's a lot more going on than the reasons you point out. Particularly damning is the fact that Paris is successfully building subways at a 10th of the cost in far less time despite having even more constraints around digging.
The recent additions to the Rome Metro were also built faster and cheaper compared to, say, the Central Subway in San Francisco, despite all the archaeological artifacts in Rome slowing down the digging.
Thats the story, but everyone who transited Van Ness during that time saw the same thing - very little work actually being done. The equipment just sat there idle most of the time. A more efficient process could have come in and finished the work,
block by block in far less time if they actually, y'know, worked on it. People in construction tell me that it's because they're always waiting on the other guy to finish their job before they can do theirs. Where's the Gantt chart for Van Ness? Where's the accountability?
There was a Grand Jury report analyzing the causes of the delay in the Van Ness project. While the unexpected conditions of the underground utilities is cited as the primary cause, it does touch on some project management aspects that you mention as opportunities for improvement:
Ironically, more planning and analysis at the beginning of the project (e.g., by potholing and inspecting the condition of utilities underneath Van Ness may have avoided the construction delays.
I worked on that report! (Throwaway because, well, my real name is on the second page...)
The lack of meaningful technical planning was a big part of it, and so was the contract-awarding math, but I think the most striking - and generally applicable - behind-the-scenes stories were about what happens when trust breaks down at a human level. The city's internal back and forth on approving and then un-approving a subcontractor at the beginning meant that the GC was more likely to work to the letter of the contract when things went wrong later, instead of collaborating to solve problems. The one positive thing the city eventually did to get the project moving forward, according to all the information we got, was put someone with some amount of authority on the ground to talk to people.
Rereading the report now, all of these facts are in there, but I wish we'd found a way to stress this part more. You see the same thing in every industry, whether it's individuals or teams or companies working together - the best laid plans mean nothing unless the people involved are actually interested in tackling challenges as they come up. Culture eats strategy, and all that. A culture of writing a plan and then either strictly following it or throwing a fit when it can't be followed isn't a culture that can do great work.
Can I just point out how awesome it is to be discussing a infrastructure failure and one of the postmortem report authors chimes in with their experiences. Sometimes the HN community truly is amazing!
I was once told that Supply Chain and logistics are a people business. And it's true, for the very reasons you mentioned, the moment partners work according to the letter of the contract, and not the spirit, things become difficult. Trust is so easily lost...
A big part of “modern slowdowns” is everything being contracted and subcontracted - as opposed to one large company, government, or army doing the entire thing.
What are you going have consequences in the project management office of a gov contractor that probably has no real competition, besides maybe multiple years later when it's politically convenient? Fire the lower level union workers slacking off?
The fact every single major infrastructure project is a decade late and 3x over budget is just normal and tolerated by the people running the show across the US/Canada. The gov workers picking who wins these gov contracts (usually the same small set of companies) doesn't seem to care, despite extensive track records of the same behaviour. They probably have jobs lined up at these companies there afterwards.
It's only natural human behaviour to not put effort in if there's no consequences or risk in doing so. This is Public/private partnerships 101.
> It's only natural human behaviour to not put effort in if there's no consequences or risk in doing so.
That’s nonsense. That’s like saying that it’s only natural human behavior to abuse and be abused. If I put myself in the shoes of an underpaid sewage worker, that has a family to maintain, that sees the owner and investors of said private companies getting obscenely rich just by closings contracts under their AC… yeah, I’d slack the s* out of it too.
> ...That’s like saying that it’s only natural human behavior to abuse and be abused...
I think that's exactly what experiments have shown the world. There are many follow-up experiments that prove exactly that.
The Stanford Prison Experiment has become one of psychology's most dramatic illustrations of how good people can be transformed into perpetrators of evil, and healthy people can begin to experience pathological reactions - traceable to situational forces.
Those traceable situational forces can be minor and subtle things, and yet.
No. The SPE was unethical and its methodology was garbage, but the observations were valid enough. When someone refuses to commit an atrocity for you, all you have to do is ask the next person in line. You won't have to go too far down the line before you find someone who is not only willing to follow an illegal order from an authority figure, but happy to. See also Milgram.
The conclusion was self-evident before they ran the experiment, so another criticism that could be leveled at the experiment was that it was redundant.
The word "debunk" is doing some heavy lifting in those articles. "....Overall 58 per cent of people actually disobeyed the pushy experimenter [which means that 42 percent didn't.] How can we understand this variability, Reicher asked, if the agentic state is true?" What else would explain it -- and more important, what difference does it make?
Milgram found that 42% of people will administer electric shocks to someone who appears to be screaming in pain, as long as the order is given by an apparent authority figure. What is there to debunk, exactly?
Keep in mind what motivated these experiments: a desire to understand more about how the Nazis were able to accomplish what they did. It's not as if the findings of Milgram and Zimbardo were novel or controversial; they were merely trying to reproduce and understand something that the entire world had just observed.
I believe the debunking is that there's good evidence many of the participants realized they were in an experiment and the other person was an actor, but Milgram hid this in order to get a famous paper.
Does it matter? If someone may or may not be an actor by your judgment is going to cause you to possibly commit an atrocity then you should play it safe and refuse. Just in case...
It matters for the validity of the experiment, yes. Bear in mind, the chances of the experiment being real were astronomically small, as university professors are not normally in the business of torturing members of the public. As there were (iirc) small rewards given for taking part, the rational thing to do is follow the instructions. This seems like an inherent problem for attempting to study order-following in a lab.
And of course if you were a participant in the original experiment, you'd tell people, "Of course, I knew it was just an experiment, and it wasn't really happening."
You'd start by telling yourself that, so it would be easy enough to convince people looking to "debunk" the experiment later.
They told Milgram himself and he hid the interviews. From the second link above,
The new research builds upon findings from a previous study, which analyzed recordings of 91 conversations conducted immediately after the termination of the experiments. The recordings showed that most of the obedient subjects justified continuing the experiment because they believed the learner was not really being harmed.
> The conclusion was self-evident before they ran the experiment, so another criticism that could be leveled at the experiment was that it was redundant.
"It's just common sense" is not a solid scientific proof. Testing something that we _think_ we know (but have no proven) is not a bad thing.
Ish. It’s usually more useful to test hypotheses about why something is. If that something isn’t then you can’t get an answer & will often demonstrate the counter-factual.
Simple “we confirmed water is wet” tests are not very good science. Whereas “what is wetness & why does it happen” is.
> one reason there were major delays was because maps of underground sewer lines and plumbing were inaccurate, and needed to be relocated.
New York calls this "peek and shriek" [1]. No one really knows whats under the street until you start digging.
The Van Ness Bus line was particularly bad because it failed to adjust expectations and project management once this was discovered. In NY at least everyone expects it to happen, infrastructure there dates back hundreds of years.
It was also pretty predictable as literally ever major SF dog runs into similar problems or wacky underground issues (giant building sized slab of rock that no-one found? Happened. Run into multiple historic 150 year old sunken boats buried under your skyscraper? Happened…)
Are you arguing that we would have been just as slow in 1955 if "There were existing infrastructure or residents to deal with"?
The whole point of this article is that we should aspire to be better, faster, more relisilient to failures, less bureaucratic and efficient. My gut sense (subjective) is that we profoundly suck today at doing anything aspirational. But, nitpicking each of the examples as many comments here are doing, is IMO missing the point. I don't think Patrick is trying to be super objective here besides trying to be as accurate as possible with sources/number of days it took to build those projects. It is kind of silly to say "Oh, they didn't have X, Y and Z in 1955" because you cannot accurately judge what would have happened if X, Y and Z were actually the impediments in 1955. I used 1955 as an arbitrary year to illustrate the point.
The reality is more complicated than it appears but I've observed a bunch of construction projects near Millbrae CalTrain station and they finish the buildings extremely fast. A bunch of metal frames go up, then some pipes, then some wires, and then some concrete walls.
The project planning and construction is done by a single company, Truebeck Construction, and they seem to know what they're doing.
I don't know what Patrick's list is trying to illustrate but most construction projects in the US happen very fast.
Just speaking from personal experience. The methods that I observed are very modern and very efficient. The parts for the entire building are pre-fabricated and then assembled at the construction site. So the stagnation narrative is more than likely overblown and the folks that think things are slower now should visit some of those Truebeck construction sites and observe for themselves.
I don't think so at all and the evidence points to a profound stagnation in our ability to build. So, if we can't even admit that we're terrible at building fast, there is very little hope. Step No. 1 is admission and introspection:
The issue was that in this case they couldn’t — a lot of the BRT benefits came from creating a center lane, and that center lane was infeasible unless they did the utility project first.
I'm not an expert but have served on BRT CAC for Geary. They could have done side running and defer utilities to another agency at a later date, after which point move to center running. Or any other of the plethora of options that didn't involve a transit agency running a utility project.
Wherever there's a complex chain of independent workers (a government plan checker, inspector, a planner, a surveyor, an engineer, machine operators, a landscaper, a drain layer, a lawyer, ....) then the reality is that unforeseen nuance and conflicting priorities are ever compounding.
It's ideal to have an uber-specialist, an experienced and respected senior overseer who knows the industry and the project inside-out in both theory and practice, dedicated to the project. That gets things going. It's also rare and expensive - there are a lot more development projects than there are such individuals. They are powerful cards coveted by successful owning developers.
Hey if there's some delay caused by your team you can always just go back to the gov with shaking the money tin and explaining some 'unexpected outcomes'. The fact it's the same outcome every project is a feature not a bug.
if project realistically costs $100M and should take 3 years - it won't be approved due to budgetary and other political reasons.
Much easier to announce a project as $30M that can be done in 1 year, and intentionally skip over planning, and contingencies+complications.
Plan for naively simple project, like a Wordpress website, even if it is for is amazon.com.
When the project SNAFUs, go back to customer and use sunken cost fallacy to get more budget & time, until customer runs out of either Money (budget) or Patience (time), then complete the project and move on to the next "Grande Project"
Major one missing: China built 5,000 miles of high speed rail in 6 years. In California, it's been 15 years and we have 0 miles complete. Also built numerous hospitals during pandemic in a couple weeks. Demolished and replaced a bridge in 43 hours: https://www.popularmechanics.com/technology/infrastructure/a.... General pattern of completing infrastructure projects at a blistering pace - and they work.
Also landed a rover on Mars in 2021 https://en.wikipedia.org/wiki/Zhurong_(rover), but I"m not sure how it compares development speed to NASA. Designed for 90 days, lasted 4x that.
As much as the US denigrates China for allegedly trampling on "freedoms," I bet our way of doing speedy big projects in the past has a lot in common with China's current progress. You just have to quash special interests sometime. Autocracy gets shit done.
It would be interesting to look at a wider range of metrics for some of these fast vs. slow projects.
Safety: Did the fast projects result in more injuries or deaths?
Social: Willingly vs. unwilling participation. IE seized land vs. sold willingly at market rate. Coerced by gov to help build the hospital vs. paid market labor rate.
Environmental: Much easier to design and build a hydro dam when you don't need to worry about still allowing the Salmon to swim upstream.
Safety: "(2022) No major accidents occurred in the field of highway and water transport engineering construction throughout the year. There were 47 safety production accidents, causing 61 deaths. This represents a decrease of 26.6% and 32.2% respectively compared to the previous year." [1] Based on the context, this includes all infrastructure construction such as roads and rails. There were 61 fatalities in 2022, which was lower than previous years. There have been increasingly stringent regulations on workplace safety in recent years, which have resulted in a significant reduction in deaths and accidents. However, there is still room for improvement. For comparison (though the definitions may not be identical) in US, "From 2003-2020, 2,222 workers lost their lives at road construction sites—an average of 123 per year." [2]
Social: There was no "coercion" by the government to help build the hospital. The workers who built the hospital were paid over 10,000 CNY for 8 days of work [3]. Despite the need to work extended hours to expedite the process, possibly from 8 am to 12 am, it should be noted that the market rate for a month's work for typical construction workers under normal working hours is approximately 8,000 CNY.
Environmental: The most recent 16kMGW hydrodam at Baihetan received approval from the National Bureau of Environmental Protection despite potential negative impacts on the ecosystem. Various ecological and environmental measures were implemented to mitigate these impacts [4]. This approach contrasts markedly with that of the West or areas heavily influenced by the West like Hong Kong, where a small environmental group can obstruct major projects. China adopts a holistic approach, balancing economic needs with environmental concerns through different stages of development. China believes that as it develops, it can impose higher standards. For instance, until 2018, China imported plastic waste from the West, but halted this practice to the dismay of many Westerners [5].
I too admire how the PRC gets things done, but how is this different from “trust the government, we know best”?
> This approach contrasts markedly with that of the West or areas heavily influenced by the West like Hong Kong, where a small environmental group can obstruct major projects. China adopts a holistic approach, balancing economic needs with environmental concerns through different stages of development.
This is a vast topic. In brief, the relationship between the Chinese people and their government is markedly different from that in the US due to their distinct histories and cultures. The Chinese exert much more informal influence on government officials through culture and traditional norms than in the individualistic US, where influence is typically exerted through law or voting. Chinese government officials are often likened to the common people's parents - a concept that may be difficult for many Americans to comprehend, especially if they've been educated on theories like The Social Contract. This notion harkens back to Confucius's Book of Rites, which states, "When a ruler loves what the people love, and hates what the people hate, then he is what is called ‘The Parent of the People.’" [1] This quote encapsulates the ideal level of trust that the Chinese population holds for its government. However, this trust (alongside the respect and authority granted to officials) only persists when the government can deliver results for the people. The saying "当官不为民做主，不如回家卖红薯" or "If one is an official and does not serve the people, it is better to go home and sell sweet potatoes," may sound silly, but it encapsulates the values ingrained in Chinese government officials from a young age. This is not merely a concept that everyone knows, but it is also common knowledge, forming a significant part of the culture. Is this system perfect? No. Can it be applied universally, for example, to the US? Definitely not. However, throughout thousands of years of Chinese history, this system has generally aligned the government with the people's interests from a Chinese value system perspective.
It's been 15 years and we have 50 miles of guideway complete, with 39 more underway; 41 structures complete, and 29 more underway¹.
Some of the completed structures include:
- The Cedar Viaduct, a 3,700-foot-long bridge over State Route 99 in Fresno, which features a signature double arch design².
- The Hanford Viaduct, a 3,300-foot-long bridge over the Kings River and State Route 43 in Kings County, which is the longest structure in Construction Package 2-3²⁴.
- The San Joaquin River Viaduct, a 4,700-foot-long bridge over the San Joaquin River and North Avenue in Fresno County, which includes a pergola structure to allow future trains to cross over the existing BNSF Railway tracks²³.
- The Tuolumne Street Bridge, a two-way bridge that spans the Union Pacific Railroad tracks and future high-speed rail tracks in downtown Fresno²³.
- The Fresno Trench and State Route 180 Passageway, a two-mile-long trench that will carry high-speed trains under several streets in Fresno, including State Route 180²³.
It's nowhere near 5,000, but this whole CAHSR isn't going anywhere... it's going! Slowly but surely. Would I like it to be done before I have grandkids? Absolutely. As the proverb goes though: Blessed Are Those Who Plant Trees Under Whose Shade They Will Never Sit.
There has to be a middle ground. The US did some amazing things without autocracy, such as the public works projects under the New Deal [1] [2] [3], the Marshall Plan [4] for helping to rebuild Europe, the Federal-Aid Highway Act [5] to build 41,000 miles of Interstate highways.
I don't know why things are so difficult now. There's got to be some detailed studies into this problem.
The Federal Highway Act was pretty bad! They plowed interstates through poor (and usually black) neighborhoods to get to the city centers and at least contributed to the urban dysfunction that's been a feature of American cities since.
Then perhaps that’s a point in favour of the current regime which makes large projects difficult to build. If now we have more consultation with stakeholders then it may be less likely for that sort of thing to happen again.
Again, there's got to be a middle ground. It is insanely frustrating that in the 1960s, we were literally able to evict people and destroy their homes in order to plow interstate freeways through downtowns, but in the 2020s it takes years of preparation and meetings to turn a 4-lane road into a 2-lane road with protected bike lanes.
On certain high profile projects, sure. But autocracy typically embeds a lot of corruption at every level of the system which creates a drag in many ways.
A system that prioritizes loyalty and obedience to your superiors more than anything tends to have a lot of waste.
Counter point: Autocracies are actually extremely efficient, but we don't like to admit that. So, we come up with various narratives.
Let's be honest, there is plenty of corruption in democracies and autocracies are pretty damn good at infrastructure. Just not an ideal governing structure for individual freedom and things like property rights which we value higher than efficiency of building things fast.
Autocracies have more variability. There were good kings and bad ones. When the tyrant is smart and genuinely lifelong committed to the good of their people you get the most efficient system. This is the classic argument monarchists have. Problem is in reality the planets alignment rarely happened.
I agree that a good autocrat can be more effective than a democracy, but also think that bad ones are much worse. Plus autocracies are notoriously bad at picking good rulers/successors, so you end up with a lot more poorly run than well run countries.
I also keep hearing this. I keep hearing the “American infrastructure is built to last 50-100 years” (I used to regularly pass a handrail at the Wall Street station that was over a hundred years old, so example of one).
But is China’s really so bad it is going to crumble in half of that?
Which autocracies were/are efficient? Were East Germany, the USSR, Mussolini's Italy, or Nazi Germany efficient - not sure they were. They could get certain things done, but that is very different from being efficient (or even effective) in broader sense.
All fairly small places... the comparison is then maybe Switzerland, some of the Nordics etc. They all seem to be doing much better in building fast than their larger neighbors.
The US also has billionaires and billion-dollar companies deliberately trying to sabotage these sorts of issues. Elon Musk and his 'Boring Company', for example, going around promising a revolution in transportation and then just... ghosting people.[0] "Don't start your public transport infrastructure, we'll build you something objectively worse and far less scalable for a fraction of the price! Uh actually never mind though."
US ISPs also have a history of lobbying to prevent municipal broadband projects, which could provide faster speeds cheaper than large monopolies can. They get the projects blocked by promising to solve the problem themselves, then once the block is in place they just yolo out. Verizon takes massive grants to improve broadband in areas, doesn't do it, and then just... nothing.
Even H&R Block is lobbying to prevent making tax returns easier so that they can continue to be one of the only companies that can file people's taxes without screwing it up (which they do anyway).
China certainly benefits from cutting huge corners, but we also need to remember that every time there's an opportunity to make people's lives better in the US, there's a rich corporation lobbying against it to preserve the profits they're milking out of people's suffering or desperation.
Some people think that Hyperloop was purely intended to sabotage the high-speed rail project by creating the false impression there was a cheaper, easier, option on the horizon.
I am not sure why this gets repeated. Hong Kong (pre. China) and Taiwan gets shit done fast too and they are (were) not an autocratic place to live in (actually they had better environments than the US due to that most people comply without a fuss).
focusing on failures neglects the fact that even those shoddy projects build institutional knowledge. It's funny that there's one place in the US that works the exact same way, the VC/tech industry.
The wins pay for the failures ten times over. And while everyone laughs at ghost cities, with what people learned there you can build the next real city twice as fast. Effectiveness, getting things done, is more important than efficiency. In the EU and NA we now routinely need to bring military, nuclear or civil engineers out of retirement, because we've built so little that we've lost generations of knowledge.
Robert Moses famously got shit done. The problem is, everyone is a special interest to someone. Moses’ favoring automobiles and limited access highways over public transit within NYC limits in retrospect was idiotic.
This would be a valid point if it wasn’t for the fact that you can go to China and ride on a high speed train to see for yourself. Failing that, you can watch one of the many vlogs in which people take HSR to get around the country, or just talk to anyone who’s been to China in the past decade.
Chinese HSR does its own marketing. The material benefit to people around the country, particularly in rural areas, cannot be overstated.
At least California's infrastructure will last the test of time. If China's railways are anything like there global infrastructure then it will probably fall apart in less then 10 years.
I went from San Fransisco to Shenzhen. This is the kind of lies Americans tell themselves to make themselves feel better. Chinese infrastructure is 2-3 decades ahead of US in major cities - the only way you to deny this is to put your head in the sand.
> In California, it's been 15 years and we have 0 miles complete.
California had only 10 permanent employees on its HSR project, everyone else was a contractor. Furthermore, "Interest groups wield CEQA and NEPA like weapons. One study found that 85 percent of CEQA lawsuits were filed by groups with no history of environmental advocacy. The NIMBY attitude of these groups has crippled the ability of California to build anything." [0]
Other governments do not have to take the same approach. The choice is not limited to "be California or be a dictatorship", there are thousands of examples of states taking both a long and short time to do things, regardless of how autocratic they are. Another example from that article, "The Netherlands has strong unions, but the Port of Rotterdam has been automated to an extent that has proven impossible in the U.S. due to union resistance." - if you'd like to know more about how that went, see what the Port of Rotterdam has been doing [1] and what the union ultimately got for their strike action [2] - spoiler alert, they did not stop the increasing pace of automation, as US unions seem to have managed.
> Also built numerous hospitals during pandemic in a couple weeks.
So did the UK government, and then had to close them all as they weren't useful. Haste made waste. "As of 5 May 2020, six of the seven planned hospitals had opened, and by the following month all had been placed on standby. [...] almost all of the increased demand for critical care was met by expanding capacity in existing hospitals. By June, all the temporary hospitals had been placed on standby. Only two had admitted patients" [3]
> Demolished and replaced a bridge in 43 hours
This is normal these days for reasonably small spans [4]
> You just have to quash special interests sometime. Autocracy gets shit done.
You don't have to go to one extreme or another, you can allow your citizens rights and still build rapidly. Certainly, there are tradeoffs, and it depends on the history and traditions of your own country, as to what your citizens will accept. Sometimes regulations get in the way of progress. Sometimes, lack of regulations kill and maim your citizens and destroy their lives, and their childrens' lives. [5] There's no single good ideological approach that works best.
Back in the early COVID days, an airplane with PPE landed in Prague. Responsible agency has been short handed so the staff of national budget oversight agency came to help in what was a prime example of violation of budgeting discipline and just unloaded the airplane.
I could not stop laughing about that for days. Other ministries were literally excusing themselves since "they were not allocated funds to deal with the pandemic and had other matters to addend to" and "doing job of another organization would be a violation of budget discipline". And then the literal guys responsible for auditing them for such violations just broke the rules and did the right and necessary thing.
In the end, it boils down to a simple rule. If you live in a society where rules outweight the public good and you can get into trouble for doing the right thing the "wrong way", progress grinds to a halt.
Isn't that always the case? Government guys in charge of enforcing something always give themselves a pass. Generally considered a perk of the job.
E.g. policeman pulls over another person for speeding. Which of following do you think is more likely situation and for policeman to issue a warning and let them go without a ticket:
It's not a problem when "progress" is easily determined. But regulations are famously "written in blood", created after some employee was a little bit too empowered and caused an accident.
For example, I'm very happy that employees of the nuclear power plant approval committee don't ignore safety rules even if it does impede the progress of the building process.
> Tony Fadell was hired to create the iPod in late January 2001. Steve Jobs greenlit the project in March 2001. They hired a contract manufacturer in April 2001, announced the product in October 2001, and shipped the first production iPod to customers in November 2001, around 290 days after getting started. Source: Tony Fadell.
Just 290 days for the iPod to go from idea to customer is crazy fast
Impressive for sure, not to knock it. But, as I recall reading, the mini HDD for the iPod was already developed by a vendor's R&D, sitting around for a use case. Which Apple decided to take exclusive advantage of. Thus, that iPod offering seemed kind of "revolutionary". But it's not like Apple started the project, then developed all of the tech for it in this time of 290 days. Which is sort of what the summary reads like, to me. So I'm adding this comment, for clarification. (Heck, the story I read about the first iPod and its HDD was probably originally linked from HN!)
They had to design the software, the UX including the touch wheel, the mac integration and syncing, and everything relating to the design, materials, and sourcing of the components. It’s astonishing that they got it done in less than a year. (And I highly recommend Fadell’s book)
The iPod's OS was bought off the shelf. All of the music library functionality and a lot of the sync functionality already existed within SoundJa...iTunes.
That's not to knock the speed of the iPod's development but it wasn't built totally from scratch. Apple also wasn't a garage startup, peeling some hardware engineers off for the iPod wasn't going to cripple the iMac's continued development.
Everything around the software would have been quick -- both the iPod UX and syncing were extremely simple back then. The iPod didn't really have a GUI, it was just six lines of text and a header line.
It's the manufacturing speed that astonishes me -- the sourcing as you say, the supply chains and the factory capacity. I'm also very curious about the manufacture of the scroll wheel -- was that something really new that had to be figured out (it seemed/felt like it) or was it a trivial combination of existing components?
Most inventions become trivial right after they are released. Creation, research, design are the hard parts, and you cannot judge those by the complexity of the final product.
Wow, I did not know that story but it makes so much sense that the ipod was an almost inevitable development from the mini hdd. Goes to show how important it is to have people who can see the big picture and find the right people to execute.
It's worth noting that hard-drive based MP3 players did exist at the time, but they had several drawbacks that Apple found solutions for.
First, they used physically larger 2.5" hard drives, making them larger and heavier. The small 1.8" HDD that the iPod used allowed it to be the size of a deck of cards, meaning it was much more portable.
Secondly, hard drives consume a large amount of power to operate, so HDD-based players had terrible battery life because it was always spinning up the disk to get the next song. The iPod solved this by just adding 32 MB of RAM as a cache, so when you started an album the system would just read in the next 15 minutes (or so? that's about 30 MB at 160 kbit) of songs and then power down the HDD until the cache was running out or the user changed albums/playlists/tracks.
It was also fast; using firewire to transfer songs restricted it to Mac users at first, but it meant that you could rip a new CD and put it on your iPod in a short amount of time, or, later, buy an album on iTunes and have it ready for your jog in ten minutes.
It's funny to think how many people saw the iPod as an obvious immediate failure. As the infamous Slashdot post[0] said, "No wireless. Less space than a Nomad. Lame."
We got samples of the Toshiba 1.8" drive at IBM Research around August 2001 for the Super Dense Server prototype and I remember thinking how neat they were and wondering what else they could be used for.
What if they add some fast ones that were fast but that didn't work out so great, like Theranos or the submarine guys. Also Apollo 8 is in there but I mean a relatively large percent of astronauts died compared to like your company's new agile plan how many agile blackbelts do you expect to literally decease because of shortcuts taken in the implementation of their workplace environment.
Having worked at a top 5 big tech company from college hire to a high level position, I have seen many factors that contribute to things being much slower than a startup. Some of them might be valid, but others are just the result of tragedy of large organisations (a big tech company is surprisingly similar to governments in terms of internal bureaucracy).
* Large number of people and orgs willing and fighting to take credit. If you need 1 week of support from an org, forget it unless you give them large credit worth a huge amount of work. This means you need to justify that credit via creating more work.
* Centralized internal product offerings which act similar to government given monopoly companies (think AT&T before breakup). Since that is the only entity offering that product, their offering doesn't have to compete with the in market offerings and thus can be as bad as needed, as long as it is tolerable.
* Everyone laser focused on their own org size and org power. This means tons of metric chasing, a lot of which requires creating work. For instance, if writing an if else can have a big impact delivering a lot in revenue, you write 5 new applications to soak up the revenue impact and show that something big was done. (A brilliant 2 liner regardless of impact will receive some claps but won't do much for the org power).
* The slowly increasing number of incompetent hires. The politically savvy ones survive and keep moving up and keep doing whatever needed to increase their power.
The numbers get a bit smaller if you focus only on creative roles (engineering, design, etc) — but it's still an enormous amount of people. And all of them are constantly moving at the speed of realtime chat to jump on every project and figure out how they can use it to advance their careers. The politics and bureaucracy are practically inevitable at this scale.
A friend of mine was working on a contract project for a major Canadian telco. The project was almost entirely complete, just a few things left to get the client to sign off on the project and go live. None of the people involved on the telco side had a huge interest in this project; it was just something else that was going on.
Then, suddenly, it seems as though they realized that this small project was the CEO's pet project. Overnight, everyone involved suddenly had opinions on what could be changed to be better, to be friendlier. Change the colors, the fonts, the layout, move things around, pick a different image, back and forth. As soon as there was an opportunity to attach their name in a place the CEO might see, everyone was clamoring to make some kind of a difference as soon as possible.
In the end, it delayed the project by weeks and wasted huge amount of my friend's agency's time trying to push back on all of these changes on things that had already been approved, or which didn't need to be changed. Incredibly gross.
Amazon and apple’s numbers are inflated by retail and warehouse staff significantly, who are effectively political non actors as far as this dynamic goes
Amazon yes, Apple no, there is an internal difference between retail (not on slack, except executives, high level logistics, etc) and corporate. When I worked there there were 180000 people in the general channel (that includes some contractors, but the number is not that off), and that is only corporate.
Google released its search engine when it was just 2 guys.
If those two guys kept working on it for the past 25 years, but hired nobody new, I wonder what their product would look like? I suspect it would still be pretty decent.
It wouldn't ever have become what we know of as Google today.
When I worked at Google I was lucky and had coffee with Jeff Dean and Sanjay Ghemawat many mornings when my desk was near them and we had shared interests. I got the chance to quiz Jeff a bunch about the early days. When they joined, L&S had already handed indexing off to a couple programmers who had written a system that had to be run all the way through (all steps of indexing) to build a whole new index. Any failure in any step- even just one simple worker- meant you had to run all over again. That led to the development of MapReduce, GFS, and BigTable, which allowed google to scale search while also improving search prerformance (latency of a query, latency of crawling hot documents and having them appear in the index). Jeff definitely didn't have a high opinion of Larry and Sergey's programming skills.
But then, the search engine was really just phase 0 in Larry's attempt to revoluntize the world of information, sort of the things you have to do at the start of a realtime strategy game to get your tech tree up to AI.
A fun thought experiment, but I suspect they'd be bankrupt from the meritless lawsuits that come from being big, or in prison for not being able to follow laws they had to be big to lobby against.
And even if not, the combined efforts of the scammers would probably evolve faster than two people could react.
Since we are in fun thought experiment mode, here’s another one I just had: what if we somehow could prevent companies from getting too big? Would we manage to keep a line where they all stay more or less in “pretty decent” territory?
By what metric, and how would it be different than antitrust enforcement?
E.g. a product that is clearly better can legally capture 100% market share. Only leveraging that market power is illegal.
I genuinely think a rule along the lines of "anything with 30%+ market share is scrutinized as having monopolistic network effect advantage" would have net positive outcomes on competition.
The metric of user share. Wouldn't enter antitrust territory if you somehow avoid acquiring more users. Limiting # of active accounts would be one way to enforce.
Difficult to know. It would have been difficult for them to make money without adding an ads team. Without making money it would have been difficult for them to create the infrastructure to process the large amounts of data and change that are a big part of how google search works these days. Would a two man company focused on search have created google maps or google earth? Probably not - gathering just the data for streetview was a pretty huge undertaking. Their geographic search capabilities would probably have been nonexistent.
That's interesting, but I don't think it diminishes the point - a two person company would have been pretty unlikely to acquire them, or stay two person if it did and needed to integrate them with their search product.
Agreed, but why should we care whether Google was able to acquire service X or Y?
(It's one of my pet peeves when people elide the massive amount of innovation that happens in small companies which then gets conglomerated under one of 5 massive brands.)
I'd argue that Google's one major innovation is the ad-supported free business model for most of these services. From a casual skim, it looks like most of the revenue for the company that built what became Earth was from the military. Google took that and made it "free" for regular people.
I chose those because I think maps and street view and to a lesser extent earth are meaningful improvements to the Google search experience that wouldn't have been available to a smaller company.
Having worked at some startups I think there are a lot of problems too
- too many startups are founded by non-technical people. This almost inevitably ends in disaster, unless they have a technical co-founder with equal levels of decision and control
- because invariably the money is not the founder's they aren't thinking of ways to save money. Some VC funds like a16z are partially to blame for this by telling the startups they invest in that sometimes it's a good idea to burn money in order to grab land, but the point where it doesn't make sense to spend more effort on efficiency is not one which a lot of startups reach.
- a lot of the business models make zero sense, have zero testing performed on and no data gathered to attempt to validate. Just like you wouldn't build a train without some computer simulations and test models, and wouldn't launch it without test runs you shouldn't do the same for a startup
> Large number of people and orgs willing and fighting to take credit. If you need 1 week of support from an org, forget it unless you give them large credit worth a huge amount of work. This means you need to justify that credit via creating more work.
I've worked at a couple of top 5 tech companies, and it saddens me that people have such a sour/cynical view. You're saying that people don't move unless they get credit... but isn't it more likely that the people you need support from, are (1) already overloaded with work for other teams, (2) busy with their own core work, and (3) it's hard to keep plans aligned between very large number of teams, which then often makes "simple" requests difficult?
Unfortunately this has been my observation seeing internal deal making, and it becomes stronger the more higher level discussions I see. To take a hypothetical example, let's say a team owns some very simple central config store, and every now and then someone needs to get an entry added there. The speed of getting it added would so strongly depend on the favour you can do for them. A matter of adding a new key in a json file can take from hours to weeks depending on who asks.
Literally every single thing in this list was produced by a group of people moving towards a well-defined, unified goal.
But in today's FAANG and FAANG-wannabes, these kinds of efforts are near impossible because of middle-management politics. So much of time goes in stack ranking and performance reviews that no engineer is ever going to collaborate.
Perhaps CEOs are so far removed from their employees that they don't even realize what is actually going on in the company.
This may be one of the best (worst) examples of how bad things are today. The California High-Speed Rail was funded over 15 years ago and they haven't begun building it yet. They are 82% of the way through their environmental studies.
It may delight you to know, then, that they've started building, and in fact they've built a bunch of stuff for it already! As of March 2023, 50 miles of guideway are complete, 39 are underway; 41 structures are complete, and 29 are underway¹. Some of the completed structures include:
- The Cedar Viaduct, a 3,700-foot-long bridge over State Route 99 in Fresno, which features a signature double arch design².
- The Hanford Viaduct, a 3,300-foot-long bridge over the Kings River and State Route 43 in Kings County, which is the longest structure in Construction Package 2-3²⁴.
- The San Joaquin River Viaduct, a 4,700-foot-long bridge over the San Joaquin River and North Avenue in Fresno County, which includes a pergola structure to allow future trains to cross over the existing BNSF Railway tracks²³.
- The Tuolumne Street Bridge, a two-way bridge that spans the Union Pacific Railroad tracks and future high-speed rail tracks in downtown Fresno²³.
- The Fresno Trench and State Route 180 Passageway, a two-mile-long trench that will carry high-speed trains under several streets in Fresno, including State Route 180²³.
"It may delight you to know, then, that they've started building ..."
Unfortunately, "high speed" is a misnomer.
This would have been high speed rail had it been deployed before 1990.
At this time it is just "rail" and when it is finished we will be back where we started: 40-ish years behind the state of the art with a product inferior to other modes of travel.
Disclaimer: I want very badly for a real HSR between SF and LA[1] and am deeply disappointed at the - sometimes comical - concessions and degradations that have accompanied this project since day one.
[1] Non-stop express service in less than 120 minutes.
Initial funding was 15 years ago. Construction funds weren't approved until 2013 when construction contracts started to be awarded. Construction began in 2015.
"Progress continues across the 171 miles under construction and development in the Central Valley, including more than 30 active construction sites and 69 structures or grade separation projects either underway or completed."
One semi-common thread to these is how much of the invisible groundwork had already been laid, in order to execute so quickly. I wonder how much is "fast" and how much is "right time, right place" and/or "right preparation."
I'm reminded of Alexander the Great, and his massive conquests within a short lifetime. But my understanding is that his father Philip II paved the way for him, building a lot of the political and military structure that he would leverage. But people don't remember the accomplishments of Philip II nearly as much as Alexander.
For a recent infrastructure example, I would point to Beijing's high speed rail expansion. Around 24k miles constructed since 2008, and around ~12k in five years [1].
Actually, Runescape one of the most successful MMOs ever was a Java applet. Java is much more effective at complex object-oriented modeling and an MMO is a canonical example of where OOP not only shines but is necessary. Before ES6, there were half a dozen styles of approximating classes in JavaScript, the main one being with closure-returning-functions. Even utilizing these clever tricks to make JavaScript a decent language, the runtime would not have been powerful enough to run a game like Runescape. For a very long time, JavaScript was primitive in even managing media. Flash allowed Youtube to bridge the gap of playing videos in the browser. JavaScript-based web apps to stream music didn't become prominent until the 2010s, a decade and half after JavaScript was invented. Yahoo music, the prominent web-based music player in the 2000s, used a Flash plugin. So Indeed, Flash and Java did some solve a lot of problems that JavaScript did not. JavaScript won out because it was browser-native and now WebAssembly is gaining traction because JavaScript is still not that great. TypeScript is solid, but that took years of development and Microsoft resources to launch.
Runescape was crazy for the time (pre-WoW). A full-featured MMO you could play on a wide variety of computers without downloading or installing anything. All you needed was Java.
All you needed was to download a new monthly version of 50MB of JRE and install it on your virus-prone Windows XP machine and open up about 7 new holes in your system with each patch.
You probably had the JRE installed already, unless you were particularly security-conscious. Even many who were security conscious had it installed. Runescape was also compatible with the MSJVM, though the window of time where that mattered was short.
Far more apps were written in Flash than in Java Applets. Java Applets were problematic for their large file size and memory requirements. You would also need to regularly download updates for the runtime and manually run through an installer on the base operating system in order to get applets to work. They were also a security nightmare, and critical vulnerabilities continued right up until Applets were finally canned for good in 2013: https://www.cisa.gov/news-events/alerts/2013/01/10/oracle-ja...
Flash had plenty of its own vulnerabilities, but it was at least efficient for what it did with the network resources of the time.
I know the history of the web, and I know JS wasn't practical for a lot of complex apps before Chrome's v8 engine came out in 2008. That being said, it was still plenty powerful enough for apps like Gmail and Facebook.
I'm not even criticizing these technologies for existing or having been important plugins of the web at one time, I very much understand why they were used and why JS wasn't. HTML had no native video encoding, but also, the browser war held back the web standards a great deal as companies competed on the peripheral features of the web like video encoding and Silverlight vs Flash. Video codec encoding was such a mess for such a long time due to the issues with MP4 and all the patent nightmare mess that unfortunately took way longer than it should have. At least Adobe could bypass a lot of that without having to deal with the Microsoft vs Mozilla vs Apple vs Google business. And Adobe could cover the license fees for any tech it needed with its editor prices.
I get it. My point, however, is that those other technologies introduced different tradeoffs in compile time size, runtime performance, proprietary tech stack (Java is still owned by Oracle, not an open standard, to this day), mobile compatibility, etc. And none of them would have satisfied all the requirements for the web then or now. Meanwhile, since the web was able to evolve, and open standards got better and browser compatibility got better, JS is now a pretty good choice.
The idea that the creation of a game-focused scripting engine somehow reflects on the qualities of a programming language seems a bit silly (I mean this not in an insulting manner but am a bit tired and can't figure out how to structure this sentence) to me. Scripting engines show up in game engines all the time, regardless of the underlying technologies they're built on. Game-specific scripting engines allow you to have people who aren't really programmers, or programmers who aren't knowledgeable in the internals of the engine or the underlying language, to create content.
> Video codec encoding was such a mess for such a long time due to the issues with MP4 and all the patent nightmare mess that unfortunately took way longer than it should have.
Dude this isn't even wrong. It's just nonsensical and ahistorical.
Like, no, dude, it's totally sensical, historical, documented and written down for all time, part of the patent system of the United States and even if its dissatisfactional... it's actually really, truly, factual:
The parent issues around MPEG-4 had effectively zero influence on media tags in the HTML spec prior to HTML5. In the late 90s and the early 2000s it was the W3C's opinion that video and audio media was best left to plug-ins using an object tag. They were far more concerned about XHTML/DOM and related technologies than media support.
You're trying to draw a connection to unrelated issues. The MPEG-LA has a pretty clear licensing structure for h.264. Mobile SoCs with hardware h.264 decoders come with playback licenses just rolled into the cost of the decoder. Microsoft and Apple both shipped playback licenses. Adobe also had playback licenses for Flash because it supported h.264 in both FLV and MP4 containers. Only Firefox had any problem with h.264 licensing because they insisted on shipping their own decoder instead of just hooking into the OS' native decoder. That was a problem of their own making and was only really an issue on desktop Linux. The vast majority of people in the web have no need for concern of MPEG-LA licenses.
Even that is immaterial because the HTML5 video tag spec doesn't have a "must implement" codec specified. It readily supports references to multiple video sources based on what the browser/OS combination supports.
That still has nothing to do with issues around video delivery in browsers. Even YouTube didn't have HTML5-based playback until 2010 (for a limited amount of content). IE still had over 50% usage share of browsers so Flash-based video players were the most reliable means of video playback for most users.
Licensing of codecs just was not a limiting factor. Licensing for h.264 wasn't any more onerous than licensing for Sorensen Spark, VP6, WMV or Real Video video streaming sites were using before they started to adopt h.264.
It's fine to complain about software patents but don't conflate unrelated issues. MPEG-LA licensing didn't make the W3C ignore media playback for years. The MPEG-LA didn't affect IE's outsize influence on the web for a decade.
Apollo 8 is not a very good example; it's not like the hardware pipeline wasn't well on its way to be ready to go by the time the decision was made.
Don't get me wrong, Apollo 8 was an extremely risky and critical part of the program, but it's not like somebody conjured everything up from thin air in 134 days.
> On August 9 1968, NASA decided that Apollo 8 should go to the moon. It launched on December 21 1968, 134 days later
But they were planning to get to that destination, with the same Apollo program, for years before that...
This example seems a bit of a stretch, which makes me hesitate on the other examples.
And another source of hesitation comes from this parallel:
- During Covid, it was said that China built a new hospital in like 8 days, and it was claimed "we can't do that" etc
- But then we created a temporary 1000-bed hospital in 7 days: "It was much quicker than we usually design, engineer and construct a project... We worked 24 hours a day, seven days a week with our vertical team to spec out the sites [and] award contracts, and then began work immediately after the contracts were awarded." [1]
I was really interested that the current Haggia Sophia structure was built in less than 6 years. I am used to construction times of cathedrals and other religious buildings spanning multiple generations.
We like to focus on how long it takes governments to build things these days (especially US government(s)), but these discussions remind me of the Washington Monument, which was under construction for 36+ years depending on how you count it! And this was in the 1850's, when this type of construction was certainly feasible. As may sound familiar today, construction moved haltingly due to lack of funding.
“ The physical infrastructure projects enumerated above occurred before 1970 to a disproportionate degree. Why? ”
If you Google image search “growth of environmental regulation”, there is a huge increase in the slope of those graphs right around 1960-1970. A simple explanation might be that environmental regulation strangled the speed of physical infrastructure building. A more complex explanation might be that environmental regulation, along with other regulation, experienced this massive growth as a symptom of massive growth in management, consulting, and bureaucracy employment - and it is this proliferation of managers and consultants and bureaucrats that have slowed things down.
I do like the second explanation more. The Atlantic https://www.theatlantic.com/business/archive/2012/01/where-d...) tells me that “professional and business services”, their catchall for managers and consultants, grew from 2.3% of GDP in 1947 to 12.1% of GDP in 2009. This sextupling of management work could very well correspond to a sextupling of the length (in time) of projects. A mile of road takes just as much asphalt whether you build it in one month or six months, but it takes ~six times as much management when it takes six months.
> So all in all, if we control away war, and increasing complexity, and the fact that you can't optimise people beyond a certain point, and sprinkle on top some regulation-induced slowdown it's not clear that there has been a slowdown or stagnation in general for major projects.
One of the examples here is the Berlin airlift. If you are interested in the Berlin airlift, I'd really recommend the book "Checkmate Berlin" (Giles Milton). It starts in 1945 and covers the whole arc of the Soviet-Western relationship. You could argue that it is rather rah-rah anti-Soviet, but I read it in mid-2022 and was down for that. Really fun read with great spy and political stories.
One day in mid-November, workers at OpenAI got an unexpected assignment: Release a chatbot, fast. The chatbot, an executive announced, would be known as "Chat with GPT-3.5," and it would be made available free to the public. In two weeks. The announcement confused some OpenAI employees.
OpenAI's top executives were worried that rival companies might upstage them by releasing their own A.I. chatbots before GPT-4. And putting something out quickly. So they decided to update an unreleased chatbot that used a souped-up version of GPT-3 which came out in 2020. (snipped)
Some things are pretty fast considering what they accomplished.
The Lockheed A-12 was built 2 years after its designs were approved, with 2 years before that of planning. Still the fastest air-breathing airplane in existence. Its first flight was in 1962.
In March 1940, John R. Dunning's team at Columbia University verifies Niels Bohr's hypothesis that uranium 235 is responsible for fission by slow neutrons. August 6, 1945, the first atomic nuclear bomb is dropped on Hiroshima, Japan.
During the Great Depression, in 1931, the largest dam in the world, the Hoover Dam, was built. At the time, no such large-scale uses of concrete had been proven, and it was unknown how construction could be finished in a way that would cure the concrete in time and prevent it from deteriorating. Construction was completed in 1936, over two years ahead of schedule. Testing in 1995 concluded that the dam's concrete has gotten stronger over the years.
Given how impossible it is to build anything here anymore the spped in which the Victorians built the railway network in the UK amazes me. 6,000 miles of track were built in 1846-1848 alone.
A classic 20 year old article on the principle of Stop Energy.
"Stop Energy is not reasoned, it never takes into account the big picture, it is the mirror image of Forward Motion. In the Stop Energy model, everyone, no matter how small their stake in a technology, has the power to veto. Nothing ever gets done, and people who want to move forward are frustrated in every attempt to move. Unfortunately, Stop Energy is the rule, not the exception"
Very interesting thing(maybe sample representativeness) is that there aren't any "fast" things from the 2010-2020 decade. Does anyone have anything impressive in mind? Personally can't think of anything myself.
The entire ride-sharing/delivery/logistics space was moving ridiculously fast during that time.
Remember those photos of thousands of multicolored bicycles abandoned in fields? Or the scooters being yeeted into the ocean, global riots from taxi drivers, the collapse of the taxi medallion market, regulatory debates in every city/state/country, billions of VC money raised in weeks (or days), the Darwinian M&A scene as companies were devoured in the jungle as quickly as they were founded...
...and, of course, the fact that you could finally push a button and make a bag of groceries appear. (Though the 3,600,000 millisecond latency still isn't great on that one.)
Even though this in the long run may have burned more money than it yielded, I think this also represented a pretty landmark shift in how people saw computers (including smartphones). They were no longer just devices for surfing the web or messaging. Between this, and the rise of Amazon/online shopping, computers were now ways to actuate the world
IIRC, a lot of that was enabled (at least in the US) by the wider-scale rollout of 3g and smartphones. Before that, not only did few people have smartphones (uber initially had both a website and phone number you could contact to get a ride for at least a few years), but even metropolitan service areas were too spotty for near-realtime apps to work effectively.
COVID19 vaccine was 2021, wasn't it? Just slightly outside the decade.
A lot of war-equipment got spun up in 2022 and 2023 extremely quickly, but I don't think people are talking about that.
-----------
EDIT: The 2010s through 2020s were a period of incredibly low interest rates and cheap money. Most projects were thinking long-term, for good reason. When interest rates are 0% and you got free money / free borrowing, there's not much point in doing anything quickly.
We've got stupendously stupid ideas like MoviePass getting deployed, and bankrupted, within months. Does that count? Presumably we want something that wasn't "just" fast, but also impressive / accomplished something real.
The vaccine development happened effectively in a weekend. The long period of time to develop isn't related to science, it's the bureaucracy afterwards that took so long. So depends on the definition.
Isn’t that partly the point of the linked page? That one of the things contributing to how slow things go these days is that bureaucracy can grind quick developments to a halt?
Depending on where you draw the lines, maybe Oculus. I think from the formation of the company to shipping dev kits was less than a year, but there was obviously research and prototypes that happened prior to that, and it was a while before they were shipping consumer devices.
Redis barely misses the decade cut I think, with an early 2009 start to a production launch and rapid adoption starting around mid-2009.
About 30% of interstate gas pipelines were built between 2007-2017 as one of the many consequences of the shale boom. Global LNG trade doubled in the same window.
Germany installed 6 (floating) LNG import terminals in 2022.
California built five gas-fired power plants in a few months in 2021, after a blackout.
We can still build things fast when there is institutional will to do so.
I think it only took a couple of years from 2014-16, and it was marked as being decades away by many experts at the time.
I also remember lots of ridicule about Instagram only being a year or so old, when it was acquired, and possibly some of the Space X rocket development programs count as ‘fast’ although I don’t know all the details.
The examples in Fast aren't breakthroughs, they're just big engineering projects. AlphaGo's design is quite simple, the estimate of decades was prior to the discovery of the unexpected power of deep neural networks.
Fun fact on the Eiffel Tower: during the Chicago World's Fair, they wanted to build something that would rival the Eiffel Tower. After a LOT of proposals, and work, and time, they came up with... the Ferris wheel.
> The physical infrastructure projects enumerated above occurred before 1970 to a disproportionate degree. Why?
Probably because the author either can't count or doesn't know what disproportionate means.
1/3 of the entries on the list going back to 1889 happened after 1970 (which is about 1/3 of the timespan). That sounds very proportionate. Why no questions about the long gap after the Eiffel Tower?
The most disproportionate things about the list are World War II and the fact that the list is extremely arbitrary.
In the UK we have been debating building 1 more runway at 1 airport for about 50 years and still it’s not settled. Meanwhile China has built several entire islands in the ocean and put airports on them.
> Construction start was delayed two weeks to allow the 42 families living on Pine Point, which was scheduled to be demolished to build the shipyard, to move.
It’s also a great example of “headlines without reading the article”. There’s no discussion of consequences, and some of the items don’t really reflect how much work had to go on after the initial effort to make things what they are today (JS and git being prime examples).
My son built a fort out of couch cushions in just six minutes, and yet the city can't approve a condo tower project without months or years of public consultations and impact assessments? Ridiculous!
I recently read the book “How Big Things Get Done”, about planning megaprojects successfully, which incidentally touched on a lot of the projects here. While I mostly found the book to be worthless thought leadership, the authors thesis on why these projects were able to succeed is that they were able to “think slow, build fast”.
The iconic patrol boat river[1] used in Vietnam took just seven days to create a prototype from the civilian boat maker Hatteras Yachts. It used Jacuzzi jets.
> To determine the amount of fuel the plane would need, Lindbergh and Hall drove to the San Diego Public Library at 820 E St. Using a globe and a piece of string, Lindbergh estimated the distance from New York to Paris. It came out to 3,600 statute miles, which Hall calculated would require 400 gallons of gas.
This reminds me of when I interviewed at Stripe, a few years back. It was a surreal experience. We were in a small conference room. I sat at the table on one side, Patrick and Edwin sat on the other side. They asked me questions, I answered them. It was a good discussion.
Then there was a brief pause in the conversation. Suddenly, Patrick let off the most absurdly loud fart. I chuckled in surprise. Patrick and Edwin stared back at me, in a stony silence, neither of them making any acknowledgement of Patrick's colonic eruption. I forced myself to adopt a similarly straight face.
As the smell of it filled the room and my nostrils, I could only assume this was a power move, intended to dominate. I held my nerve, and continued the interview. Unfortunately, I wasn't offered the job. Now I wonder if maybe it was a cue to speak up and point out the loud, smelly elephant in the room. I suppose I'll never know.
Has anyone else here who's interviewed at Stripe had a similar experience? To this day, I still wonder if Patrick's fart was a deliberate and calculated part of the hiring process.
> "I still wonder if Patrick's fart was a deliberate and calculated"
I mean if it was planned then that's some impressive intestinal agency. But maybe with his diet he always got it chambered at that time of day so he can plan around it.
I have to admit this one does make me grumble a bit. Greenfields is fast! You don’t have to keep the old thing going or take care to avoid disturbing it because there is no old thing!
It seems an obvious point; I remember watching him present a version of this in person and it occurred to me sitting there.
Steady on. I’m no fan of JavaScript either but it seems unfair to damn it so completely with such a backhandedly vacuous accolade. Some folks might not even get the irony.
JS is a core component to all that in the same way that coal and oil are core to the industrial revolution: not the best, but it's easy and cheap and everyone has a lot of experience and sunk-cost investments.
Not due to some sort of virtue of the language being better. The browser devs wanted to cut down the security surface area. Javascript wasn't as removable as the plugins that used other languages were.
Modern JS is a passable language only after a tremendous amount of time and effort was invested to retrofit it as such. For all of the purported isomorphic benefits, I still don't know why anyone would choose to use it outside of being forced to in browsers
It works great for you because you haven't seen better. Which other languages do you have more than 1 year of professional experience with? May I answer that for you? None. Just because you've just discovered a knife, doesn't mean it's the best tool to eat the soup with.
Javascript, like python, was "simple yet flexible". Thats what made them successful.
When a language is successful, people start to bolt on extra bits of syntax and features (async, prototypes/classes, lambdas, etc). Eventually it is no longer simple, and the learning curve gets steeper for new users.
Someone comes up with a new simple yet flexible language, all the new users start with that instead, and the cycle repeats.
BASIC/visual basic/VB.net went through that cycle in the 90's. C then C++ went through that in the 2010's. Python/Javascript is going through that now. Go is about to go through the same.
All the "good" languages have tremendous effort - it's how they get good. Nothing starts great...it's a journey. We've been watching the sausage being made.
Just because "it's a journey" and we invested tremendous effort, doesn't mean it's suddenly great. It's a terrible language with many illnesses, even today's modern version, because it's kept its diseases from the past. It surely is lightyears better than what it used to be, but it's still a pile of turd IMO (I work with JS every day).
That’s why git and JS don’t really belong on this list without a massive asterisk. It’s not like JS you use today is the same as the one that took “10 days”. Same goes for git.
Modern Typescript is fairly decent. Plain Javascript is still awful. And I wouldn't say either are great.
I especially don't understand why Javascript doesn't have a "modern" mode where `var` and `==` are banned, prototypes are immutable, etc. You can do all that with linters but the people that need help with that stuff don't know how to set up a linter in the first place or what options to choose.
> You can do all that with linters but the people that need help with that stuff don't know how to set up a linter in the first place or what options to choose.
Then how would they know how to enable "modern" mode? Junior devs shouldn't be setting up any of that stuff anyway, they should be given a laptop with VSCode + prettier already installed, and all of the config they need should be in the project repo.
I didn't say anything about JS being bad. But this article is predicated on the assumption that doing things fast is good. I think it's hard to argue that if Eich had spent 20 days (or perhaps even 30 days!!!!) we would have been in a much better place for the last couple of decades. We're not working around the fact that JS is intrinsically a bad language, we're working around the fact that it was ridiculously rushed.
He made the world’s most popular programming language in 10 days. By most people’s definition that’s very impressive.
Sure, he did it mostly by being in the right place at the right time. But lots of geniuses tried to do web programmability before, eg with java applets. They were in the right place at the right time too. They spent man years getting it all right, and even Eich’s very first 10-day hacked version of JS (or, well, LiveScript) was better. Don’t dismiss all the stuff he got right. It’s a lot!
AFAIK core javascript works exactly like 25 years ago, and they haven't changed anything on it, not removing a single keyword or altering a semantics of any less used function, so your 25 years old javascript programs can still run in modern browsers.
Which brings up another reason why some of these projects were Fast -- they operated in places where there there wasn't existing infrastructure or residents to deal with, or cut corners on planning and mapping, which future projects now have to deal with.
https://sfstandard.com/transportation/van-ness-brt-bus-rapid...