Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Agility meets the Waterfall

Agile best practices in Waterfall-based Java enterprise development

By ShriKant Vashishtha , JavaWorld.com, 03/25/08

Page 2 of 4

The project that ate my life

A project scenario is perhaps the easiest way to explore the weaknesses of the Waterfall model. Consider a typical Java enterprise project that involves a team of 150 to 200 people. The project has been divided into functional modules, which in themselves may look like multiple smaller projects. In total, the project consists of 10 to 15 EAR (enterprise archive) and WAR (Web archive) files. To test the entire application, it is necessary to set up all the EARs and WARs. Subversion (SVN) is the source code repository and version control system for the project.

Now let's consider the day-to-day activities of a developer and a build manager, to find out what kind of challenges they face.

A developer’s perspective

The first step in setting up my workspace is to check out the projects from SVN. But whenever I take the latest build from SVN, my workspace goes haywire. As it turns out, some of the files checked in by my colleagues do not compile. I suspect some files are committed to SVN with unresolved compilation issues. I also get into trouble when the method signatures of some internal-library classes change all of a sudden. Nobody informed me! It's worse when the client library provided by an application changes but the changes aren't committed in SVN. I get runtime errors when my code interacts with the application. Worse, even if the library is committed in one project, it might have a different version in another.

Hmm, that's a lot of trouble, isn't it? As a humble developer, I just want to work on my part of the software and not bother about what is wrong with other components. Unfortunately, my part of the application is dependent on others. Also, I am just starting out as a Java developer and am not necessarily aware of all the nuances of application setup, classpaths, libraries, and so on. Believe it or not, sometimes it takes me nearly all day to resolve setup issues. I am left with very little time to devote to the project itself, which causes me a lot of stress.

I have another issue that is a kind of living hell for me: The functionality of my module comes last, in terms of the entire development project. I want to test my module but I need the data provided by all the other functional modules in order to set up the data for mine. Nine application steps come before my own. If even one of them breaks, it stands in the way of me reaching my last step. It can take six or seven hours for me to fix those other issues before I am able to test my own business case!

You might say "Aw, poor fellow," but I'm afraid that's what I am. Instead of concentrating on developing and fixing the functionality I own, I spend a lot of time concentrating on issues I shouldn’t be bothered with. Worse, everybody in the project is so busy in his or her own work. Sometimes fixing all the issues I've mentioned takes a lot of coordination, and that means a lot of time.

What I need

My needs are pretty simple: Whenever I check out the latest copy of my project from SVN, I should be able to set up the project on a virgin machine (an operating system, JRE, and SVN client) and fully build the system. For this basic need to be met, the code available in SVN should be compilable at all times. It should have the latest libraries available and there should be very few manual steps to build the whole system.

I also should be able to test my functionality, even in isolation. I just want to be able to build and test my functionality before integrating it into the bigger environment.

A build manager’s perspective

If you take a look at the problems mentioned above, my situation is no different. Right now, each application component (EAR/WAR) in this big project is individually built. Each component has a Java project and in turn has a folder containing its various dependencies. If one client JAR of a component changes, it's up to me to make sure the lib folder of all other components with the .jar is updated. That’s a manual task.

Sometimes my team members fail to update that .jar in one lib folder and everything goes downhill fast. It results in runtime errors that are hard to debug in such a complex system. Making a change in one JAR and updating it in all the project lib folders is a pain. Each application component has its own set of libraries and build scripts, so it’s time-consuming and requires continuous manual intervention to build the entire system. (Sighs.)

Oh, if everything goes well it only takes around 30 to 45 minutes to execute all build scripts and re-deploy the application on the server. But if a compilation problem comes up (which usually happens), I have to chase people around and get it fixed before I can deploy it on the server. This makes a lot of people unhappy. Developers are not able to test the application in a holistic environment. The testing team doesn’t get the application available for testing in time, which wastes their time and the company's money. People sit idle and the testing manager and project manager start complaining, and then I am in trouble again. I need an easier way to tackle these problems!

Hey hold on -- I haven’t finished yet! It is also my job to take care of the project's multiple build environments: one for development, another for testing, and yet another for performance testing. Having three build environments/machines can mean three constantly running application versions. For each build environment, I need to make changes in application configuration. And -- you guessed it right -- I need to make changes in the configuration properties file for each deployment before building the system.

Now, imagine making changes in the configuration properties of a system that contains 15 EARs manually, just to make a build. That's a mechanical job? Ha! I simply hate it, and my team members hate it even more.

What I need

I should be able to execute the system build with a single click. It should require minimal-to-no manual intervention. I also need a way to track whether code in various modules is compilable and ready to be built and deployed. Because we need to create builds for different environments on a regular basis, I need a mechanism to automatically configure properties for new build environments. I also need a way to update JAR files across all projects. Essentially, I need to be able to make changes in one place and have the changes proliferate to all concerned projects.

Common needs

The needs of the developer and build manager in the above scenario probably are familiar to you. It is easy to see that a developer working on a specific piece of a project should not have to bother about the project's larger technical infrastructure. Likewise, anyone can understand the build manager's need to minimize manual efforts and focus on other important tasks in such a big project. I summarize the developer and build manager's needs for this project as follows:

• It should be possible to check out a project, make minimal configuration changes, and build it on a virgin machine.
• Code checked into the SVN repository should be compilable and ready to build at all times.
• The latest libraries should be available in all Java projects at all times.
• It should be possible to test individual code modules without dependencies related to other projects.
• it is important to track whether all project environments are ready to build or not and keep the information where everyone can see it anytime.
• It should be possible to make configuration changes in one place to create a new build for any environment.
• It should be possible to update internal jars in one place, so that every individual component is affected by the change instead of making changes in lib directory of each and every component.

In the next sections we'll see how certain best practices in agile development meet these needs, even within a Waterfall-based project.