The author definitely makes a mistake in equating slow programs with poorly-written programs. Yes, it's true that people who write horrible code often also wri

The author definitely makes a mistake in equating slow programs with poorly-written programs. Yes, it's true that people who write horrible code often also write horribly non-performant code, and that rushing a product to market without performance testing is far too common in our industry. But in my experience (and I've done a lot of performance tuning), making something perform generally requires selectively damaging the code by making it less understandable and by breaking rules about encapsulation and separation between layers. There's a reason why that whole "premature optimization is the root of all evil" saying is so popular. Performance tuning is also incredibly time-consuming and labor intensive. It might make you feel more hardcore to do it, and it certainly be a useful intellectual exercise, but it's still time that could well be spent on other types of product improvement. The increase in clock speeds has been a primary driver behind the ability of people to use higher-level languages, as well as the ability for people to write larger and more complicated applications. So assuming that a stop to the increase in clockspeeds will lead to better software is flat-out wrong; if anything it'll help to essentially halt certain kinds of progress in language and framework development by preventing people from using higher-level abstractions that don't perform as well.