The application of Agile values, principles and practices is totally orthogonal to the programming framework/platform you use. That is, there is nothing to say about a "J2EE developer perspective on Agile", as far as I can tell.
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
Originally posted by Ilja Preuss: The application of Agile values, principles and practices is totally orthogonal to the programming framework/platform you use. That is, there is nothing to say about a "J2EE developer perspective on Agile", as far as I can tell.
Originally posted by Ilja Preuss: Agile Software Development an OOP are totally orthogonal concepts. Basically, the former is about how you organize your team, the latter about how you organize your code.
Ilja, I know what you are trying say. However I disagree that Agile Software Development and OOP are totally orthogonal. While nothing in test driven development demands OOP, in my view OOP has simplified the construction and use of unittesting frameworks like JUnit to the point that people are willing to try it and expend the "perceived" additional upfront effort. Thus OOP has enabled the practice of TDD which includes continuous refactoring - these are core practices of Agile Software Development.
I believe that without (true) OOP development tools realizing Agile Software Development becomes a lot more daunting. See also my comments in Is Agile only for Java.
Even in J2EE the use of EJBs with the their lengthy compile-deploy cycle initially made TDD difficult (You just couldn't do it often enough). Many session beans tended to contain procedural transaction scripts rather than recognizable object-oriented designs. It wasn't until small-scale (i.e. unit) testability became a design goal, realized through the use of JUnit and Java's OO features, that TDD could be practiced with relative ease.
Peer, I agree that procedural code isn't as easy to test as object oriented code - simply because for unit testing you need to isolate units, and procedural programming just is missing important tools to isolate units of code from each other.
I don't think, though, that OOP is the only way to get isolated units of code. With my limited experience, I'd assume that functional languages, for example, are probably as well suited for Agile development as OO languages.
And I seem to remember that Kent Beck once claimed that he learned the basics of Test Driven Development from his father, who was programming in assembler.
I do a lot of work in a J2EE environment, and the main problem I face when trying to introduce or encourage an agile approach is the reliance on code-generation IDEs. It seems that, to a lot of people, being a J2EE developer is all about knowing which buttons to press on an IDE to generate a whole slew of configuration and source code files.
This may seem "agile" initially, as it gets things going very quickly. Things slow right down as development progresses, though. Either battling with the IDE to make it generate exactly what you need, or manually hacking the generated files and abandoning the advantages of code generation.
When you add to this the test-unfriendly nature of most of the J2EE APIs (they assume and reqiure to be running in a container, and can't easily be tested in isolation) I do find that the parts of each project which are "J2EE" are usually the least agile.
To minimise this problem I typically use as few of the J2EE facilities as I can get away with, and make them the thinnest of thin wrappers around ordinary, testable, Java.
Originally posted by Ilja Preuss: I'd assume that functional languages, for example, are probably as well suited for Agile development as OO languages.
I won't quibble there. In some respect functional languages may be superior to OOPs especially as some of them may be also more productive. My beef is with development environments that still are largely procedural or that have "productivity enhancing features" like components that "automagically" bind against the database and push parts of the data model all the way up to the user interface.
Originally posted by Ilja Preuss: And I seem to remember that Kent Beck once claimed that he learned the basics of Test Driven Development from his father, who was programming in assembler.
Assembler code isn't necessarily procedural. While C isn't an OOP, judicious use of a void pointer (sacrificing some type safety) allows you to separate "interface" from the implementation (C Interfaces and Implementations: Techniques for Creating Reusable Software); the same should be possible in assembler. The "dangerous" features of C probably made the development of Cunit possible.
And while TDD can conceivably be used in a procedural development environment, the lack of support for interfaces makes mocking much harder, ultimately hindering adoption of TDD.
With all that being said, and not much to disagree with, I still think that none of it is something that should make you choose a non-Agile appraoch over an Agile approache.
True, testing, refactoring etc. can be much harder in some environments. That doesn't mean that we should abandon it, in my view - we just should work harder to make it possible. Not testing or refactoring the code just because its hard simply won't improve our situation.
And let's not forget that there is a lot in Agile approaches that isn't effected by the coding platform very much - such as the approach to planning or how to organize the team.
Joined: Aug 19, 2005
Originally posted by Ilja Preuss: True, testing, refactoring etc. can be much harder in some environments. That doesn't mean that we should abandon it, in my view - we just should work harder to make it possible. Not testing or refactoring the code just because its hard simply won't improve our situation.
You are preaching to the converted here. However statements like "we just should work harder to make it possible" are often enough to convince some teams and/or the people who are in charge of them to stick with the old (ineffective) way of doing things - even though they are the ones that need the change most. While Agile Methods are becoming more common place they are hardly the norm.
By saying that "we just should work harder to make it possible" you are acknowledging that certain development environments will require even more 'discipline' than others. The problem is that many places adopted heavy-weight processes as means to verify compliance in a situation were 'discipline' was not fostered or lacking entirely. In situations like that it is hard to introduce agile methods to begin with and if the development environment is "unhelpful" it's just not going to happen.
Yes - It is true that by and large the "coding platform" shouldn't matter very much - however having a coding platform that makes certain practices ("Refactor Mercilessly", "Continuous Integration", etc.) relatively easy makes the transition that much smoother.
Admittedly, people are still looking for the silver bullet when they ask for 'agile' tools - they want to be able to say "I use X - I'm agile". And as Frank pointed out it doesn't work that way. Certain tools (or certain ways of using them) can get in the way. To be agile (in the coding context) you just need some basic tools like a compiler/runtime environment, version control tool, a testing framework and a text editor. However you need to know these basic tools well to use them effectively. If you add a build tool things might run a bit smoother. Once you add a refactoring browser/editor (and you know how to wield it) now things are starting to feel more 'agile'. So if you use the Java JDK, JUnit, Subversion and Eclipse (and optionally Ant or Maven) does that make you 'agile'? Nope. It depends on how you use these tools (again just limiting things to coding context here). (See also Scott Ambler�s Agile Modeling: It's Use the Simplest Tool not Use Simple Tools)
So far I have seen little guidance on how to implement the coding centric practices that are part of agile methods in a "stone-age legacy" development environment that would foster the weekly or bi-weekly iteration lengths (there is a lot of software out there that simply will not be re-written). It seemed that the original XPers wanted to use Smalltalk but then had to "settle" for Java even in the face of the associated loss of convenience and productivity simply because the mainstream would be resistant to maintaining Smalltalk applications. I'm a big fan of Michael Feather's Working Effectively with Legacy Code. However most of his examples are in Java with some smattering of C++ and C. "Legacy Java code"? I should be so lucky.