Hmm, I'm not sure we disagree. I think you're looking at a larger picture. I think the scope of most software was somewhat narrower at the time these opinions w

Hmm, I'm not sure we disagree. I think you're looking at a larger picture. I think the scope of most software was somewhat narrower at the time these opinions were formed, and I believe in his mind Dijkstra was thinking about the structure of individual programs more so than the architecture of systems or technology based business. This strikes a chord with me because I was thinking just other day about the fast vs. good trade-off, and I have come to the conclusion that "fast" doesn't mean poor quality. It means, or should mean, that you build fewer pieces, attempt fewer features, but the individual components that you do build are still well structured, well-designed, well-implemented, and don't close off avenues of evolution as the business scales. In other words, for me he is saying that code must always be written well, as simply and as elegantly as possible. You still retain the freedom to choose how much to write.