Project management methodology or coding style?

[Lars Behnke]

Hi Martin,

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.

- Lars

[Adeel Ansari]

Originally posted by Lars Behnke:
What's special about agile code as compared to conventional code?

Bad Smells in Code and Continuous Inspection might provide you an idea.

[Ilja Preuss]

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.

[Adeel Ansari]

Do you guys think "owning the code" comes under coding style. I don't think so.

[Robert Martin]

Originally posted by Lars Behnke:
Hi Martin,

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.

- Lars

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.

TDD is the practice of writing unit tests, and writing them _first_. See the three laws of TDD. (http://tinyurl.com/2ktm24)

Refactoring is the practice of cleaning the code.

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.