What are your efficiency gains by removing XML in java projects ?

Question

I have just moved from phase 1 to phase 2 of a project. In this transition we got rid of all of the XML configuration for spring and struts2, switching to a fully annotated regime.

All of the participants are amazed at the actual effect this has on development speed. There are a number of reasons for this:

• Structured thinking about which roles are needed lead to clear understanding that we needed @StubRepository, @TestService and @NotTestService annotations to facilitate all the different run-time models that our project uses (runtime, unit test, integration test, selenium test)
• These annotations replaced a large number of duplicate xml definitions.
• All dependencies are fully trackable in the ide.
• Simpler to work with code because dependencies are clear

Some of these gains could probably have been realized by re-structuring the xml as well, but that would not have been a trivial task.

I honestly believe this has given somewhere around 10% boost in productivity for our 20,000 man hour project. I almost find it hard to believe.

Anyone else sharing this same experience ? What's your gain, and how do you explain it ?

Answer 1

I don't have productivity figures like you but I have seen significant improvement when moving from xml configurations to annotations. I think its because the configuration information is in the same place with the code.

Before you had to look at a separate file to find configurations and that slowed things down.

Answer 2

Basically, this could be viewed as a question about config files vs. annotation.

If you experienced an amelioration in productivity boost when putting some data as annotations, that means they were not "configuration" material in the first place.

The difference between the two:

• annotation: everything is in one place and the configuration information is associated directly with the Java component. Many types of refactorings of the source code are transparent to annotations for this reason -- the annotations will always apply to the component they're attached to, even when that component is moved or renamed. For other refactorings that require new or modified annotations, everything is in the same location, assuring that the annotations are visible to the developer and increasing the likelihood that they'll remember to make the necessary changes.

• Configuration files can provide an organized view of a web of relationships that span different components of an application. Because they're separate from the actual source code, they don't interfere with the readability of the Java source code.

What you experienced is the disparition of the need to maintain config files in parallel with the source code of an application, with no obvious connection between the two.

BUT: annotations have their drawbacks: source code can become cluttered with all sorts of annotations that are irrelevant to the actual program logic, interfering with the readability of the code. And that while annotations are ideal for metadata that relates to a particular component, they're not well suited to metadata with cross-component application.

Answer 3

(I really didn't mean to respond with a bag of cliches, but XML seems to bring out the proverb collection... ;-)

I have found XML configuration (and config files in general, but that's another question) to introduce multiple levels of your question, because, "To a small boy with a hammer, everything looks like a nail." It is easy to become enthusiastic about a tool (such as XML) and start using it much more widely than it deserves, or to keep adding "just one more" feature until the result becomes too unwieldy.

Also, as the old saying goes, "Everything in programming is a trade-off."

So, to play devil's advocate, have you reached the point where you need to do maintenance or tweaks on the running system? In the new scheme of life, how often do you have to make adjustments by re-building all or part of the system, instead of being able to tweak a config file?

Finally, there's rough equivalent of the "Hawthorne effect" (see below). Sometimes a team gets a burst of excitement when they are allowed to clean up some minor issue, and they achieve a burst of productivity out of proportion to the actual improvement, triggered by the relief at getting rid of a long-standing annoyance.

Footnote:

The Hawthorne effect is named after a study of factory worker productivity relating to changes in lighting. The researchers found that increased light was followed by an increase in productivity. But then they found that decreased light was also followed by an increase in productivity. (Both increases were typically short-term.) The final conclusion was that the workers were more productive because someone was paying attention to them.

So, sometimes an otherwise trivial change triggers a boost in morale (sense of empowerment, etc.) that causes improvements in performance.

There's seldom just one factor.