Using a metaphor for your software system is a good way of describing how the system should work in a way that other people can easily relate to. This has been described in the eXtreme Programming 'System Metaphor' practice. However, is this really necessary? And what happens if your system changes or you divide your software in more modular parts?

Hamlet D'Arcy writes in his blog entry:

"The eXtreme Programming System Metaphor practice makes a pretty easy target. I've seen large development teams grind to a halt because of persistent broken builds without any continuous integration. I've seen teams' productivity drop to a crawl under the burden of technical debt and lack of test driven development. But what happens when a team lacks a good metaphor for how the system works? Can you really name a reasonable, realistic negative impact from a lack of system metaphor? Just last week I was dismissing it in an internal agility training as an unneeded XP practice. So I was surprised to see Joshua Kerievsky's and Brain Foote's "System Metaphor Revisited" talk at Agile 2009. Seriously, the guy who wrote Refactoring to Patterns is also hyping the System Metaphor? We'll see... "

Java is a great programming language, but everyone who uses the term knows that it is much more than that. At a minimum, the term includes, the JVM, the API libraries (the language is almost useless without them.) Of course, in any practical application that includes so much more: frameworks, functional libraries, coding conventions, development infrastructure such as unit test and continuous build, and so on and so on.

 The gist of my post is that far beyond all these technical extensions to "Java" as a technical term, I tend to think of "Java" as a development and software engineering culture, and, for me, that culture implies an attitude of learning. The technology of the Java environment is evolving so quickly that learning is just plain part of the normal ongoing routine. 

Great developers are naturally part of great teams. Great teams are great in part because they allow their members to flourish and become great. A key element of that greatness, in my opinion and in my experience, depends on continuous, ongoing learning. 

James Shore has written a nice introduction to Agile, targetted at QA people. Inspired by the following question:

The company I work for is looking to make changes in how our software development cycle works (we currently use a waterfall-type method), and the higher-ups have decided to start moving towards a more Agile development cycle, with the appropriate, "sprints" and whatnot.

I've read a bunch about Agile development, and it's gotten mixed reviews. Has anyone experienced it, from a QA perspective? What should I expect from this? Am I out of a job? :-(