Links June 2020

From last year, a Politico long read on the difficulties in building a new Penn Station: “In the first decade of the 20th century, it had taken New York a mere four years and seven months to build the first leg of the subway, running from City Hall to upper Manhattan. In more than double that time nearly 100 years later, the city had made next to no progress on Penn Station…In the decades since, that gospel has been used to justify a whole choirbook of incantations—efforts to require projects to mitigate even the slightest environmental effects, to preserve landmarked buildings no matter the cost, to democratize land use decisions so that not-in-my-backyard stakeholders can reject even projects of great public benefit, and much more. By many measures, the movement to devolve power has been wildly successful. But more than four decades later, the trade-offs have become more evident. Nowhere is the evidence starker than at Penn Station.”

By way of Alex Tabarrok, here is another example of the promiscuous distribution of veto power, this time in Germany: “…local opponents of the wind farms often go to court to stall new developments or even have existing towers dismantled. According to the wind-industry lobby BWE, 325 turbine installations with a total capacity of more than 1 gigawatt (some 2% of the country’s total installed capacity) are tied up in litigation. The irony is that the litigants are often just as “green” as the wind-energy proponents — one is the large conservation organization NABU, which says it’s not against wind energy as such but merely demands that installations are planned with preserving nature in mind.”

Most software at Google gets rewritten every few years. “This may seem incredibly costly. Indeed, it does consume a large fraction of Google’s resources. However, it also has some crucial benefits that are key to Google’s agility and long-term success. In a period of a few years, it is typical for the requirements for a product to change significantly, as the software environment and other technology around it change, and as changes in technology or in the marketplace affect user needs, desires, and expectations. Software that is a few years old was designed around an older set of requirements and is typically not designed in a way that is optimal for current requirements. Furthermore, it has typically accumulated a lot of complexity. Rewriting code cuts away all the unnecessary accumulated complexity that was addressing requirements which are no longer so important. In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”. Frequent rewrites also encourage mobility of engineers between different projects which helps to encourage cross-pollination of ideas. Frequent rewrites also help to ensure that code is written using modern technology and methodology.”

By way of Alec Stapp, a theory on rioting:

1. An event occurs that signals to would-be rioters that they may soon be able to riot.
2. This event gathers a crowd. A significant percentage of this crowd—though rarely, it seems, the majority—are eager for destruction.
3. An entrepreneurial would-be rioter tests the crowd for the presence of other rioters by engaging in a minor (yet easily perceived) act of carnage.
4. Other rioters follow suit, and as the number of offenders grow so does their willingness to take increasingly brazen acts of vandalism, theft, or violence.