Live Blogging the JavaOne Expert Panel on Agile Java Development

Again I'm giving the real-time caveat. The Panel:

• Dan Rawsthorn, Agile Coach
• Scott Amber, Ronin International, uses Agile
• Daniel Steinberg, Teaches Agile
• Joshua Bloch, Java Platform Architect, uses Agile like methods

How do you formulate and document requirements? Dan Rawsthorn - priorities features and requirements by business value but adding WBS(?) Dan Steinberg - FIT and FITNESS(?) document requirements in a way that are executable. Scott Ambler - involve stake holders, involve stake holders. If you don't have that your toast. Joshua Bloch - use use cases! The write interfaces to the use cases before you write code. Do programmers need to do documentation? Dan Steinberg - documents that are pulled from code are great. Bad documentation is stuff like that which you have to write by hand. Joshua Bloch - you must write API documentation. This is critical. Once the API is documented you can even think of alternate implementations. Javadoc can be used to do this very effectivly and it helps keep API and docs in sync. Rawsthorn - it depends (laughs). Unit tests are the best documentation. Bloch - rebuts - unit tests are great but you need docs for APIs because they may not have implementations. Rawsthorn - no the API is the documentation. Bloch - so you don't care if J2SE APIs don't work the way we say? Rawsthorn - no, as long as they work. (Duh!) Ambler - there is agreement here, we just don't want to write documentation for the sake of documenting things by fiat. (I'm paraphrasing.) Bloch - API docs must be concise. How does architecture fit in with lightweight methodologies? Bloch - architecture if critical, you must think before your code, if you buy them a beer they'll admit this to you. (laughs) Ambler - emphasis on the light architecture. whiteboard diagrams, napkin diagrams, index cards, etc. Bloch - violent agreement, be light, but think hard about it and the issues. What about ilities (scalability, reliability etc.) ? Ambler - do it from day one. Rawsthorn - have to get at them very early. Abler - if you don't write code you in fantasy land. Bloch - use cases should document these ilities. Critical when designing protocols, file formats, etc. Do tools help you slim down a process? If so what tools? Ambler - white board and markers. Stop caring about fantasy tools and lets here about what we do in the real world to model. Let's talk reality. (heavy paraphrasing here) Agile is all about automation. Tools help automate. Rawsthorn - Yellow sticky (what is he crazy? Those things fall off whatever you stick them to after a while.) If you want to persist them persist them to a wiki Bloch - Those tools are so analog. Use modern tools like emacs and vi (laughs, but he's serious.) Steinberg - He likes IDEA Bloch - I'm not dissing IDEs just big ugly molding tools. Ambler/Rawsthorn - there are some good modeling tools ( you mean beyond white boards?) Is XP applicable to all projects? Amber - No. XP is good for some but not for others. Use the right process for the right job. It depends on the people. You have to have the right skills and mindset. But different people same project and XP could work. Steinberg - You can't use XP for all projects but you have to know what it is before you can dive in. However identify pieces that you can use today. i.e. Test driven development. XP might be the right way to teach programming but not for Bloch - test first is applicable to all projects. Rawsthorn - use cases support the team (lost some of his comments.) Ambler - you have to question the competence of people if you've never heard of XP. A lot of these techniques are in your future. Interesting comments from QA: Rawsthorn - Military saying "When your map and the terrain disagree, believe the terrain." Ambler - get a stakeholder or cancel the project. Ambler - it's going to take a generation to absorb and fully adopt Agility. It's similar to uptake of OO programming. Bloch - Its all about people. If you have good people they can overcome geography and time zones.