Dijkstra interview (subtitled, 24 mins, 300MB) [mpg video]
cs.utexas.edu
cs.utexas.edu
http://mirror05.x264.nl/Dark/Flash/dijkstra.html
(Direct link: http://mirror05.x264.nl/Dark/Flash/dijkstra.mp4 , 44MB MP4)
And that's very hard to achieve and market/sell.
+ He doesn't take into account the technical advantages that make new features plausible (Live Preview in Office 2007 comes to mind).
His views are a bit extreme, but still we can learn from him. Although we are not programming for non-existent machines, I've found(the hard way) that thinking hard about a problem can save countless man-hours in development(of unnecessary features), debugging(an overly-complex implementation) and maintenance(of inflexible designs, that result from diving straight in problem-area you don't understand).
I enjoyed the video because I haven't seen him before, but it's far from the dense talks I'm used to.
May be I should read his Turing award lecture.
Interesting.
I find the exact opposite is just as effective. When I stop thinking so hard and just release the problem, a much better approach often comes back to me when I least expect it. This is a very hard thing to do. Once it worked a few times, I learned to develop a little faith in my inner "background processor".
I should have said "thinking clearly about the problem (which is ofter hard) can save ... ".
I've seen too many people writing code that "looks like it's solving some part of some problem that's similar to the problem at hand". This might actually work when the problem is ill- or undefined, but it shouldn't be the default (and only) way that software is developed.
However, you wrote "just release the problem" (as a contrast to "thinking hard"). I agree that straining over a problem often doesn't help. I think that the kind of elegant solutions Dijkstra admires are more likely to come once you've absorbed the problem, and be receptive to solutions from your unconscious. Henri Poincaré It is by logic we prove, it is by intuition that we invent
But I don't recall Dijkstra ever speak of intuition. Maybe for him, straining did work? One thing I've found is that straining to create a better representation (simpler, only the key things) does seem to help. It's fairly straightforward, but hard work. It helps because I can then see the problem - and my intuition can come into play.
Over my career, I have shifted towards iterative development. I think the change in the way I develop applications has come about because I have a much better feel for where things can go wrong, and I have learned that you can never fully anticipate where problems will arise.
I still have some reservations about freshly minted developers working iteratively, mostly because I fear that there are some things they will end up learning the hard way that more seasoned developers wouldn't make. I think that risk can be successfully mitigated by having junior developers work with mentors.