In my opinion, true agile is rapidly getting code in the hands of users as quickly as possible. Then iterating on that. You don't need a lot of requirements to get started. But need to be not afraid of change! Things will change (maybe everything will change) and that's ok -- plan for change. This author starts with the implicit premise that change is bad and all conclusions are the result of that.
I've been involved in a few "Agile" projects implemented in hard-to-change platforms. And ultimately it's just disguised waterfall -- if you can't change the product then you're doing big planning up front.
Where in the article do you draw this conclusion from?
Change isn't bad. The article doesn't say change is bad. Change introduces complexities. And unclear or ill-defined objectives (aka, requirements) make change more likely.
How did you come to that conclusion? The theme of what I was saying is that projects to be given direction from the stakeholders. I never said anything to suggest that the direction couldn't change.
If programmers are coding whatever they want based on wildly unfounded assumptions then they're not doing Salmon Ladder development -- they're just terrible developers. If they're given some direction, coding, and iterating on that result then that's great. Even if they make some wrong assumptions at first, I don't see anything wrong with that.
"Don't start without requirements"
Depends on if you even know what the requirements are, some projects are just an idea.
Before you start writing software, have at least one
clear objective. You might call this a requirement, a
user story, or a specification. Give the developers a
target to shoot at. Otherwise, you will be swimming
upstream.
Even producing the prototypes meant you probably had some objectives unless someone just typed something out one day entirely on a whim.
Why is it so unimaginable to create something without being able to articulate it beforehand? Or why wouldn't it be possible to start with something and letting it evolve by discovering new insights while building it?
How many successful things are really built by first writing down requirements?
Sometimes it is just an personal itch or curiosity. Other times it is actually total epiphany that brings success...
When a project or task is individual or trivial, then who cares. When not, a "hack it 'till it (hopefully) works" approach doesn't cut it.
Edit: grammar
If its a business process, lack of any form of requirements is how technical debt is guaranteed from the start.