6. Bring Back Moore's Law hmmm, maybe developer cycles are more valuable than machine cycles really is getting out of sync with current conditions? I didn't c

6. Bring Back Moore's Law hmmm, maybe developer cycles are more valuable than machine cycles really is getting out of sync with current conditions? I didn't connect stalled clock-speeds to the web being slow til reading this. One reason is that web-serving is usually embarrassingly parallel, as each client is independent. Some other causes are increased client-side JS; assembling many services (eg. amazon); increased usage with resources not keeping pace. But pg's point is surely a factor too. Bloated frameworks, and software with many layers (some quite unnecessary) were facilitated by increasing clock-speeds - but at least it's possible to get rid of them. Also, work has been done on JS JIT compilation. Server languages are getting faster too. This may seem like a tangent, but bear with me: Clayton Christensen (who coined disruption) makes an interesting point about "integrated" (closely-coupled, interdependent) vs. "modular" (clean interfaces enabling mix-and-match) architecture. The advantage of integration is you can make it perform fast - you can optimize "performance" according to a variety of definitions (e.g. smaller, lighter, more memory, less battery power etc). This wins when customers value increased performance - Christensen describes this willing to pay more for performance as it "not being good enough" because once it's good enough, they won't pay for more of it. The economic advantage of modularity is you can develop fast, you can create and customize more quickly. Part of this is reusing components (e.g. buy off-the-shelf or open source, or reuse internally) - this wins when customers value that over performance. This usually doesn't happen until performance is "good enough": if it's too slow to use, who cares how configurable it is? An example is iPhone/iPad (integrated) vs. Android (modular). The iPhone/iPad is fast, light, slim, long battery-life, better resolution, smoother animation etc. In contrast, there are many different Android devices, with different prices, displays, shapes etc, and many have customized UIs. Christensen's fascinating point is not that one approach is better than the other, but that they change over time, cycling back and forth. It depends on what the market wants at the moment: what will customers pay for more of? Following the example, once smart-phones become "good enough" in performance, customers will start to buy on other factors, such as price. This seems to be starting to happen for smart-phones; but not yet for tablets. In relation to pg's observation of server slowness, it seems that formerly, performance was good enough, and so the developers that were most successful favoured mix-and-match layers, because they were faster to develop and easier to customize. But now, performance is a problem... which may mean that developers who favour integration will be most successful. It's not black and white, but an interesting perspective.