Agile Engineering - Refactoring: The Questions

Refactoring, TDD and Solutions Spikes are most known engineering practices that are fundamental for an Agile process.

Refactoring - "…is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior." AND "Refactoring is a controlled technique for improving the design of an existing code base." (Martin Fowler)

Question 1 - Why we need Refactoring in Agile Development?

... and for the ones that have the answer to the first question

Question 2 - It is enough to refactor in order to enable agility? What other practices could help? (other then TDD and solutions spikes)

Oath of a Clean Coder (cloned from Hippocratic Oath)

As you see in the previous post, Uncle Bob has a list of expectations from the software professionals. He use also the term Clean Coder to describe a such professional. He also says that our life will depend more and more on software, and for this reasons "We need to be!" professionals.

Our life.

It is the same thing as in the healthcare domain. Even the healthcare is depending more and more on software. The physicians take the Hippocratic Oath , beyond any other rules and official laws. Why? Because it is important. What about the software used by these physicians? This Oath has no effect for the software...

We will need a similar Oath - a kind of Clean Coder Oath:
(Note - In fact, Martin book Clean Coder start (some years before this post) from the idea of Hippocratic Oath and present a code of conduct for the professionals developers. )

I swear by Apollo, the REFACTORER and Hephaestus, and I take to witness all the gods, all the goddesses, to keep according to my ability and my judgment, the following Oath and agreement:

To consider dear to me, as my parents, him who taught me this art; to live in common with him and, if necessary, to share my goods with him; To look upon his children as my own brothers, to teach them this art; and that by my teaching, I will impart a knowledge of this art to my own sons, and to my teacher's sons, and to disciples bound by an indenture and oath according to the ENGINEERING  laws, and no others.

I will prescribe DESIGN for the good of my SOFTWARE according to my ability and my judgment and never do harm to ANY CODE.

I will give no SPAGHETTI CODE to any one if asked, nor suggest any such counsel [...]

But I will preserve the purity of my life and my arts.

I will not cut for BUG, even for SOFTWARE in whom the ERROR is manifest; I will leave this operation to be performed by practitioners, specialists in this art.

In every SOFTWARE house where I come I will enter only for the good of my CODE, keeping myself far from all intentional ill-doing [...].

The main question is: how many times we have break such rules and principles? How many times the programmers start to "cut"  or build parts that are beyond their skills? How many times the programmers have delivered a (too) bad code?  How many time the programmers have harm the code?
Too often ...