Originally posted by Frank Carver:
In many ways java is less suited to an agile approach than some of the more fluid languages (Smalltalk and Ruby spring to mind, although there are many others.)
But you are still talking about languages with OO features which are inherently suited to
test driven design. Personally I think that TDD is a pivotal practice when it comes to being "agile". However there is still a significant body of custom software out there that was developed before the rise of Java (or before it gained widespread acceptance) that either used a pre-OO development environment (not even C or C++) or some RAD-era inspired Smart GUI tool. The owners are unwilling to consider re-writes "merely to improve maintainability" but this software still has to adapt to today�s changing business needs (It�s sometimes mind-boggling for how many years some custom software systems, "at the brink of being decommissioned", continue to perform mission critical services because the owning company is "not in the business of writing software"). I consider these types of development environments TDD-adverse/TDD-hostile - not to say that TDD is impossible (though it may seem that way, especially if you have to write your own testing framework) but the "cost of admission" is significantly higher than it would be with your general OO development environment.
For example, many Oracle shops invest heavily in their PL/SQL stored procedure code base (possibly to the point that the PL/SQL code IS the server-side application). Even though Steven Feuerstein has supplied a testing framework (
utplsql), unit testing never really got "fashionable" with the PL/SQL crowd. Without OO-features it is notoriously difficult to mock aspects of the code for testing or inject dependencies. Furthermore the kind of partitioning that testable code requires feels to some PL/SQL practitioners like "swimming upstream". And because of the size (and/or interconnectedness) of the databases that are involved you will rarely find a situation were each developer has their own database instance (sandbox) to do their own unit-testing. So even if you had unit tests it would be unlikely that they would be run frequently enough.
From that I have to conclude that being 'agile' is so challenging in a TDD-adverse/TDD-hostile development environment (either because of the limitations of the tools involved, or because of "cultural pre-disposition") that most organizations in such a situation would never attempt it.