Review: Agile Development: An Expert Roundtable:

Cutting Edge Issues

Brian: There's a book out now called Balancing Agility and Discipline: A Guide for the Perplexed. People are trying to map the success-oriented goals of agile development within a larger context. In larger organizations, you can have teams that are operating in agile environments but under the umbrella of a deeper process.

Venkat has written a book on pragmatic agile development ( Practices of an Agile Developer, coauthored with Andy Hunt). The book's goal is to get the individual reader to look in the mirror, come up with his or her own goals, and ask how the reader is preparing for those goals. That is an interesting perspective. We don’t often turn things inward. But people are starting to come up with the notions of an agility index which measures how one is operating as a professional, responsible, productive member of a team.

David: There's an effort from Carnegie Mellon called the PSP— “Personal Software Process” which uses that inward-looking concept. I don’t know where PSP ranks as being agile/non-agile, But PSP involves lots of introspection. I've heard some talks about it and I really liked what I heard.

Venkat: hink about programming technology languages and tools. Take object-oriented programming (OOP), for example. OOP came out in 1967 but we didn't adopt it until mid to late 80s. Now, almost 40 years later, we still have people who are trying to adapt to object-oriented programming.

Methodologies have the same kinds of problems. The computer industry changes very frequently but the rate at which the industry adopts a methodology is extremely slow. There are initial adopters. Then at a certain point, the practice of a methodology gets mainstream acceptance. Agile development has been around for a while but it’s not at the point of massive adaptation yet. Some people have not heard about it, or have heard about it, but have not used it at all. I'm seeing some clients who are very new to agile development, and others who know about agile development but don’t know how to use it effectively. So one of today's challenges is to teach the people who don’t know about agile development. Another challenge is to make sure that the people who think they know about agile development know exactly what it is, and to make sure that they use it for the right purpose and to the right effect.

BB: Do people misunderstand agile development? What are the common pitfalls/misconceptions?

Brian: They say: “It's agile, so I don’t have to write documentation.” Hans Wegener has a diagram that maps technology upheaval and domain upheaval to various processes. The idea is that a stable domain with a stable technology base supports a more process-heavy approach, like CMM. So for example, people in the aerospace industry or the defense industry know what they are doing and what their goals are. (That is, the domain is stable.) The programming language and platform is chosen for them, so the technology is also stable. In such situations, a process-heavy approach can help.

If the domain is stable, but the technology comes and goes, then model-driven architecture may be best. You can model the domain and then spit out technology in Java, in C#, in C++, and so on. The technology can change but the domain does not. Agility really fits in when the technology is somewhat stable and the domain is not so stable. Agile development started in the Java world where there isn't too much technology change because you're not crossing language boundaries and platform boundaries. But you're working in a very unstable, Internet-oriented, Web service domain. Customers don’t really know what they want. Customers change their minds all the time. That's where agile development started. But agile development is beginning to move into the fourth quadrant— the quadrant with low domain stability and low technology stability (the quadrant labeled "don't do this" in Wegener's diagram).

Venkat: Brian is correct. But at the diagram's far right extreme, the domain may be very stable but those working with the domain may not understand it. This can be problematic. This pushes things towards the left quite a bit. Agility could creep in and become useful in the bottom-left of the diagram. A domain expert’s point of view is that he or she knows the process but doesn't know how to deal with that in a computerized system. In contrast, developers know how to write the code, but they may not understand the domain. Where these two meet is an area where problems arise.

Brian: That gets back to David’s interest in mapping agility into the more stable domains—the domains that expect a more process-heavy approach.

David: Two things that harm the mindshare of agility. First, some organizations use agility to justify bad practices. They don’t want to do better documentation. They don’t want to gather requirements. They don’t want change the way they do things, so they say “we’re agile,” and they think that agility justifies whatever they are already doing. The second harmful thing is a when a group takes sense activities, starts doing them all the time, and calls it Extreme Programming (XP). The name Extreme Programming scares managers. The XP methodology is based on common sense ideas but the name "Extreme Programming" keeps it from being widely adopted.

BB: So, you're speaking in favor of Extreme Programming, but not in favor of the name "Extreme Programming."

David: Extreme Programming can be a bit dogmatic. You have to do ten things or you’re not doing extreme programming. But the principles behind XP are very common sense principles. I don’t think it should be an either/or approach. I think we need some kind of transition scale from more agile to less agile, depending on the foundation upon which you're building.

Venkat: If you ignore the things you need to know before you get into agility, then agile development degenerates into hacking. But agile development is not about people not knowing things and hacking. Agile development requires very competent developers. If they're working on an object-oriented system, they have to know object-oriented technology very well. They have to understand important design principles, such as the DRY ("Don't repeat yourself") principle from the Pragmatic Programmers, the Open-Closed Principle by Bertrand Meyer, the YAGNI ("You aren't gonna need it") principle of Ron Jeffries, and several other object-oriented design principles. The combination of all these principles gives us a guiding framework that allows us to focus on agility.

BB: Is there something in particular that, when people are actually doing agile development, they tend to get wrong?

Venkat: People say "We do unit testing,” but their unit testing is not effective. They're not doing it the right way. People say “We use continuous integration,” but the way they use unit test integration is not effective. They complain that there are too many error messages and they start turning off the messages, or they don’t check code as frequently as they should. “Yes, we do iterative and incremental development, but each cycle is two years long.” People think the solution is to use a certain practice or tool. But they need to go back and ask "Do we use this effectively?” The most important thing is to have a mentor in the team when you start developing with any technology or any practice. In this regard, agile development is no different. If you throw your team into something they learned over a weekend or from a book, the team will not be effective. One way to succeed is to have a mentor, an architect, or a lead developer who can work with the team and help the team learn over six months to a year.

Brian: It reminds me of Zen Buddhism. When people are meditating, they fall asleep. So there's a guy who walks around with a kindly rod to whack people on the back of the head or legs to keep people focused the goal. In Zen the goal is enlightenment. In the process world, the goal is to create software that the customer wants and to produce it on time. It's good to have someone with a kindly rod to go around and smack people, politely and gently, to keep them focused on the goal.

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.

Elsewhere on internet.com:

WebDeveloper Java
Lots of Java information on webdeveloper.com

WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.

ScriptSearch Java
Hundreds of free Java code files to download.

jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.