The Problems Of Reuse

Danny Lagrouw has commented on a blog entry called Reuse is vastly overrated by David Heinemeier Hansson. Basically, the conclusion is that often reuse is simply not worth the struggle.

I couldn't agree more. I have seen so many examples of efforts of trying (too hard) to "design something for reuse since reuse will save us so much time and money". Designing something to accommodate for future business requirements is extremely difficult since these requirements tend to be changing rapidly. You almost never know in advance the exact requirements of future uses of your code.

There are several problems with designing for reuse:

• Trying to design for generality in advance typically leads to overdesigning in a very non-XP way. This in itself might increase the costs of developing the general solution which can then be reused.



• There are always little twists which make two seemingly similar usecases different. These little differences tend to make the general design jump through loops in order to cater for the differences. It typically makes the general code less easy to read and maintain due to the handling of the differences and it definitely adds to the costs.


• Even when to usecases are similar when developed, I have seen many examples of business requirements "drifting apart", requiring the general code to adapt to the new gap between the usecases. Adapting to changes in one usecase may prove to be difficult as the changes apply to the general code. You need to be really careful with changes to the general code as it affects all the implemented usecases. And we're not even talking by the extra efforts in testing, since all the implemented usecases must be re-tested.
  

This is not an excuse for not creating quality design. I'm not saying that you should just copy-and-paste your way through the application - the DRY principle (Don't Repeat Yourself) still holds. However, I think it is important to really think carefully of whether reuse is feasible and find the right spots to reuse.

WebWork 2.2 released

WebWork 2.2 has just been released. I'm really looking forward to see the progress in Struts Action Framework 2.0, now that the WebWork developers have gotten this thing out of the door.

Nominated for Top Contributor Eclipse Award

This is so cool!

I just discovered that I have been nominated for the
Top Contributor Eclipse Award.

While I hardly think that I'll win the prize since the other contributors mentioned in the Bugzilla entry deserve far more recognition than me, it's still really nice to feel that people value my work (even though it's some time since I released any changes to my plugins).

Why does it have to be so complex

I know, it's been said so many times before... But why does web development with Java EE have to be so complex?

I have previously worked with EJB 2.0 which felt like a pain... The turnaround time was horrible (the compile, deploy, test process took about 2 minutes). And it felt especially bad since most of the functionality offered by EJB was not even necessary for the project. It was a great relief to switch to another project where Spring Framework was being used.

Still, however, the complexity of doing simple things is rather high. At my current project, we use Struts, combined with a homegrown framework (which itself adds to the complexity while adding some functionality). Adding a new page involves so much XML configuration and boilerplate code that you wonder when you're going to do some real coding.

This is one of the main reasons why I have been smitten by the Ruby on Rails bug.

I think Rails has a sensible, pragmatic approach to web development. As David Heinemeier Hansson has often stated, Rails is not everything for everyone. The purpose is not to fulfill all needs for every possible web application but rather to ensure that it makes life easier for the bulk of applications. IMHO, this is a very healthy way of seeing things.

I think many Java developers -- myself included, although I'm working on it :-) -- in general have a tendency to want to do everything the "right way" from the beginning and always with the approach that "what if the customer/framework user/etc. want to do this in the future..." This is so non-pragmatic!

I think a problem in the Java world is that there are simply too many options. I like the fact that Spring is able to integrate multiple APIs for the same purpose (ORM APIs, for instance) with a more or less common interface. I know that these APIs fill different niches on the ORM market (perhaps quite large niches), but it just adds to the complexity. Sometimes it would be easier to stop and think whether you really need it all. As Java developers we have a tendency to want a framework be able to do everything for everyone, preferably being configurable (in XML) for any possible situation. I don't think this is a bad thing in itself, it just complicates matters. There is no way this is ever going to be simple (Anders Hejlsberg calls the phenomenon simplexity when you try to take something complex and try to "pretend" that it is simple by wrapping it in something simple).

One of the extremely nice approaches in Ruby on Rails is the focus on "Convention over Configuration" (i.e. using defaults as long as you adhere with the conventions, eliminating the need for configuration). This is so obvious and yet so powerful. Very often, I have had the feeling that I'm just repeating something that the framework should have been able to figure out itself. Basically, the use of "smart defaults" could eliminate so much of the configuration (if not all) as well as a whole lot of boilterplate code.

So far, I have only used Rails on a small pet project, but it really feels right. The defaults chosen by the framework are sensible and intuitive and really makes developing web applications more fun!

I really hope to get an opportunity (i.e. an excuse) do some Ruby on Rails development on a real-life project so I can see, whether the promises and my initial impressions still hold true.

In the Java world, I'm pleased to see that the focus on simplifying things is increasing. Spring 2.0 will bring a simplfied syntax for a number of typically used configuration cases (such as JNDI lookups, transaction configuration and AOP pointcut definitions). Also, they are focusing on adding smart defaults for obvious settings.

A project I intend to follow closely is the new Struts Titanium (Struts Ti) which is the "merger" of the WebWork framework with the Struts framework (in reality, it is basically a rebranding of the WebWork name). What is interesting, beside the fact that this completely different implementation of Struts should still be able to support legacy Struts web applications, is that the team is focusing closely on simplifying development of Web applications along the lines of the Ruby of Rails framework. There is much focus on intelligent defaults based on naming of actions, pages etc.