[mannykannot]

Coincidentally, The Cassini mission to Saturn comes to its scheduled end in a few hours. From what I have read about how NASA develops software, it is essentially a waterfall process, and I am fairly certain that its programmers have more than a vague idea of what they are doing when they write code.

Edit: Do you really want to be an evangelist for mediocrity? You should give thinking things through a try; none of us get it right even close to all the time, but I think you will be surprised by how effective you are at it.

[wvenable]

I'm not saying we shouldn't be thinking things through but we aren't often blessed, as developers, with working with actual rocket scientists who will provide perfect models of the product such that it won't literally crash into another planet 1.2 billion kilometers away.

Sometimes you have to do the work and build something that isn't fully specified. Or when management says they want a Facebook clone and then walks away, you have to be willing to say "no, you have to come back the table on that one".

[mannykannot]

I think we are in agreement here - I acknowledge that the waterfall approach doesn't often work and that spacecraft are a very special case. In fact, I was going to write that waterfall is a straw man in that no-one tries or believes in it any more, but that made me think of NASA (and possibly aerospace in general), which demonstrate that it works (and is possibly the only thing that works) in certain circumstances.

I think the pendulum has swung too far the other way, however, and it is not hard to find opinions (and Stack Overflow comments and sometimes answers) stating, in effect, that the only valid way to develop code is to write some and try it. For the most part, I think these authors have not considered of how much thinking ahead goes into making even that work, and if they did, they would not be so dogmatic about deprecating it.

Three areas, of definite relevance to ordinary commercial applications, where I think thinking ahead is more or less essential to success, are security, concurrency and performance.

[wvenable]

My whole line of thought actually comes from misunderstanding the point of the article. My original reading was that it was dismissive of jumping in and coding as a method of working out requirements -- which I disagree with it. I think jumping in and coding is one good way (but not the only way) to work out requirements with stakeholders.

Instead the article is about programmers who code without the involvement of stakeholders at all. The inclusion of agile is a bit of red herring.