One tenet of Agile development is that the system is kept flexible to be able to deal with newly emerging requirements. For the code to be that flexible, it needs to be - and needs to be kept - very clean.
So, while clean code is good not matter approach to development you use, it really is a vital requirement of all Agile approaches.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Aug 15, 2004
Do you guys think "owning the code" comes under coding style. I don't think so.
The title of your book implies that agile software development is about coding style.
What's special about agile code as compared to conventional code?
In my understanding the focus of agile software development is on lean project managment and quality code is not a matter of PM methodology. Do you disagree? I guess so.
Agile and Lean have a lot of similarities. However, Agile is very specifically about writing software. So although the PM principles of lean still apply, there is more to Agile than just those lean principles.
Two of the primary agile disciplines are Test Driven Development (TDD) and Refactoring. These two are tightly coupled. You can't do Refactoring without TDD, and you won't do TDD for long unless you practice Refactoring.
The result is (or at least should be) clean code. If you don't have clean code, you are -- quite plainly -- not agile. To be more blunt about it, if you don't have clean code, you aren't being professional.
Now, you don't need to accept _my_ definition of clean code. In the book we are very precise about what we think cleanliness is. We also admit that there are other standards of cleanliness. The point is that whether you adopt our standard, or someone else's, you must stick with it. You cannot call yourself professional unless you do.
More to the point. You cannot call yourself a professional if you ship code that is less than the best you can do. You are not professional if you ship code that you do not _know_ works, and that you cannot _prove_ works by running a suite of automated tests. You are not professional if you expect QA to find all your bugs for you.