Came across an interesting post via The Pragmatic Architect by Tim Fennell on Everyone and their dog is using Struts. He has a list of reasons why:

“Managers/developers are not aware of the alternatives to Struts”

I think most managers in corporate IT shops realize there’s options beyond Struts. At least the monster hype around JSF should have reached them.

“Struts is dominant so it must be the way to go”

This is a strong argument in it’s favor. Out of all the java web frameworks its still the leader despite the dustiness of age.

“Availability of developer who know Struts vs. perceived ramp up time for something else”

Again this is pretty accurate. Inertia is pretty difficult to overcome.

“Absence of books, articles etc. on alternatives”

I think frameworks like Webworks have become a bit more compelling after having books published on them. Pretty much other than Struts and JSF there aren’t any java web frameworks with much in the way of books.

“Alternatives are not “better enough” to warrant changing”

This is the single most compelling argument for me. There still isn’t a clear successor to Struts. JSF was supposed to be, but it hasn’t really happened yet, especially the 1.0 release. The other frameworks might be a lot better, but they haven’t really taken off so you’re going out on a limb that you’ll build apps that a few years later no one understands.

“It’s a corporate standard/other apps already use Struts”

Yuk, corporate standards. This can be dangerous. On the other hand I continue to see third party commercial Java apps that almost always have their web interface written in Struts. If we buy those apps it is nice to have developers who understand how they work.

We actually have some pair programming going on within one of our current projects. It evolved pretty naturally and not as some grand plan. There were two developers, one feature to work on that has requirements, and one developer who needed more mentoring. They’re doing TDD and using mock objects. The mock DAO objects allow them to make more progress than relying on a JDBC interface to our legacy system. I may even get to pair with one of them tomorrow and write some tests as well as a nice Friday bonus.

The Java Posse podcast recently interviewed Bruce Eckel. About 32 minutes into the first of a two part interview Bruce says the following about the Java IO library:

“I don’t know if they (Sun) are just in denial or what. Opening a file is still a nightmare.”

It was good to hear one of the Java luminaries speak to this fact. I remember teaching an intro class on Java to about 24 people and explaining all the wonderful PrintWriters and BufferedReaders. For the majority of the class it was completely confusing. And despite hand waving about you need these streams because the file might be located across the network it was still very hard to grasp. It’s another one of those things where I have to look at some sample code every time I need to actually open a file in Java.

Anyway Bruce’s solution was to write a utility class to handle it.

I witnessed a developer on one of our Scrum projects today. He was called on first and spent 5 minutes not answering what he was working on for the day or how many hours were left on that task. Instead he:

• Twisted the shoelaces on his shoes.
• Stared at the floor.
• Said ‘umm’ maybe 20 times.
• Asked several times could you just tell me how many hours I said for that task.

Everyone got the feeling the developer really didn’t want to be there. The funny thing is this person is a pretty good developer who really contributes to the project. It was painful enough that other developers tried to answer for him after a few minutes. He finally agreed to 8 hours more on his current task after 5 minutes.

Some good observations from our Scrum coach on the situation: (She had picked up on the same vibe from the developer.)

• We’re following a rule that the daily standup reporting starts with the person to the left of the ScrumMaster. Since this is often the same developer who hasn’t bought into the process it starts the whole standup off on a down note. So change up the starting person so that this person is near the end and doesn’t bring the group dynamic down.
• Focus on the people on the project who are buying into Scrum or are at least open. You convince them of the value and then let peer pressure work on the disillusioned developer.

Did a little hunting today into a TimeAndMoney library I came across from Keith Ray. Nice to see an attempt to cover simple date and money functionality, since dates have always been a bit of a pain to deal with. I swear I have to look up some example code every time I do anything with dates in Java. And despite knowing better I often see floats used for money calculations and some interesting bugs tend to occur.