Note that there are quite some mistakes in the subtitles, many of them changed the meaning. For example "We mogen niet uit nonchalance fouten in een programma aanbrengen. Dat moeten we systematisch en met zorg doen." (12:00) is translated to "We should not introduce errors through sloppiness, but systematically keep them out." whereas it should be "We should not introduce errors through sloppiness, but do this [the introduction of errors] systematically and with care."
Because version 1 should be feature-complete and perfect like a Mozart composition.
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.
"...thinking hard about a problem can save countless man-hours in development..., debugging...and maintenance..."
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 misread that as "just release the product", which is the iterative development that perturbs Dijkstra. I think it can work really well for hill-climbing problems, where you have the right basic idea, and just need to keep tweaking it. But then you get enmeshed in those initial assumptions, like vines dragging you down... and you can never leave that hill.
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.
I write programs that are used in operating industrial facilities, and I used to think that iterative development was ill-advised under those conditions because it would be too easy for things to go wrong.
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.
You're right -> when you're stuck it's often a good idea to step back.
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.
