> Myth 1: Good design will emerge from the implementation of user stories ... However, in practice the code does not have this tendency to self-organize.
Code may not self-organize, but a small team of programmers can. It is not the implementation of simple user stories that produces good code but rather the ability and willingness of the team to constantly refactor the code. The main point of Agile development is that you get better quality code written faster if you take a somewhat messy codebase and refactor it, instead of try to come up with a great design before writing any code.
> Myth 2: It will always be possible to pay the technical debt in the future ... However, in practice it is not so easy to pay the technical debt.
Agile doesn't claim it's always possible to pay technical debt in future, otherwise there would be no need to refactor code. What it does say is that programmers have a tendency to overestimate the chance that the chunk of code they are working on will need to be clean and flexible in future (ie. "You Ain't Gonna Need It") and to overestimate the cost of future refactoring if it does. A good example is copy-and-pasting: It's generally fine to copy and paste a chunk of once or even twice - only on the second or third copy should you start to refactor it.
> Myth 3: Constant refactoring is an effective way to produce code ... However, in practice refactoring is consuming an exaggerated amount of the efforts invested in software development
There's no question that constant refactoring takes as a significant chunk of time in Agile, but not much more than the design phase in other workflow processes. And in my experience it is simply the way to maximise the long-term addition of value to the codebase. It's a bit like that old story about how the fastest man to chop down trees spends most of his time sharpening his axe.
> Myth 4: Agility can be assured by following an Agile process ... However, in practice the process alone is not able to provide change-resilience
Again, this simply has not been my experience. The only time I have found refactoring to be painful and difficult is when the codebase has had bits of code gingerly tacked on over the years without any refactoring - and that certainly isn't The Agile Way.
> The consequence is that some teams implement new features very fast in the first iterations, but at some point their work halts and they start spending most of their efforts in endless refactorings.
News Flash: It is ALWAYS easier and faster to write code on a greenfield project than a large, old codebase - dumping Agile will not change that. At the risk of sounding elitist or relying on the 'one true scotsman' argument, maybe the author has simply not worked with people who are good at refactoring. It certainly is a skill and many programmers don't have it. Here's a great quote [1] written seven years ago on this point:
> "for me, a lot of the differences between the best programmers I've worked with and the worst are simply the quality of the abstractions when they pull out pieces of code to reuse. Often, even when it's clear that someone needs to build a piece of reusable code to call from many places, the results will be very different. Some people are naturally good at producing clean and elegant abstractions to reuse, while others' abstractions tend to leak and be a little hairy looking, making them harder to work with."
[1] http://www.reddit.com/r/programming/comments/2d2e0/theres_no...