[threeseed]

> This is how actual quality software that will stand the test of time gets designed and made ..

No not really. It's called waterfall and we had it for decades.

And it was largely abandoned in favour of agile development because despite architects spending months designing something there was always something that was left out. Or the scope changed during those months. Or millions of other things that change whilst your hidden away from your customers/end users instead of delivering them new value every week.

For me personally the truth is somewhere between agile and waterfall. Some upfront design but not the slow code you refer to.

[jrochkind1]

I disagree, I think "waterfall" (at least in stereotype) would be more like coming up with the specifications in advance and then _sticking to them_ regardless of new information from the world or from the experience of developing the software. That's not the story the OP told.

I also agree with the person who responded that there is a difference between building products, and building tools for building products -- building shared libraries/code/tools may require different approaches. One of the things I've noticed about shared code, is it's _much harder_ to fix rethought decisions or change paths. "Backwards incompatibility" doesn't even exist as a thing in your local app really, at least you can always at least theoretically global search and replace when you change APIs.

I don't think we've figured out any magic bullet process for developing software. It's definitely not the stereotype of "waterfall", but I don't think the stereotype of "agile" is it either -- at _least_ when it comes to shared library/tools. And I'm absolutely convinced that those shared tools which do well were almost always designed carefully and intentionally with understanding of the domain, not just slapped together with stimulus-response.

[tree_of_item]

I think you're being downvoted because trying to slap a brand like "waterfall" on the very idea of slow, careful design is kind of ridiculous. Bonus points for throwing "agile" in to the mix as well.

[irrational]

But waterfall or agile implies code is being written. My take on this (and experience) is that sometimes you just takes weeks, months, even years to just make notes in a notebook, ponder and think upon the problem, jot down more notes, look around at other peoples code, do research to see if anyone else has done work in this area, do more pondering and thinking and note taking, talk it over with other people, etc. At some point it all gels together (when that happens it is almost magical and such an amazing moment of clarity) and then you are ready to use some sort of development process to actually write the code. Though by that point writing the code is extremely easy since you have such clear insight into what needs to be written. I love when that happens.

[jalfresi]

You missed the part where the definition of the problem was being percolated during this process. Agile won't save you from not understanding the problem you are trying to solve.

[kochthesecond]

There is a difference between building products and tools for building products.