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.

It’s a classic binary argument in the software development arena. Do you want developers to be specialists or do you want developers to be capable at almost any development task and specialized on a few. I’m borrowing the term generalizing specialist from Scott Ambler.

I completely buy the generalizing specialist argument. Agile methodologies assume anyone on the team can step in and help out say writing/reviewing a use case or troubleshooting the ant deployment task. On Agile projects a whole team of specialists makes little sense and sends you straight back to serial development. Instead of the team being able to self-organize, many of them end up waiting on dependencies from others. And because the specialists are the only experts in an area, they are unlikely to welcome much of a review process of their work since it’s hard for novices to review the work of an expert.

A classic example here would be breaking up a team into specialists on front end and back end development. Say the front end developers pretty much get there code in place with the proper validations and AJAX type features. Then they’re stuck waiting on the back end developers who are familiar with object relational mappers and other technologies. Then of course maybe you have specialist DBAs who are the only ones allowed to do database design so the picture gets even worse.

A conversation with our company’s architect brought this up. He explained to me that the thinking is that we’ll have a few specialists who can do business process modeling (BPEL) with WID (Websphere Integration Developer). After I pointed out that my thinking was a little different. He countered with the idea that as a developer he isn’t very good at GUIs, so he’d rather leave that to a specialist. He’s good at BPEL (true) so he should specialize on that.

The arguments pretty much come down to:

• Specialists have really deep knowledge that can be powerful.
• Vendors like IBM often sell the idea of having very specialized roles. (I’m sure this isn’t to reinforce having to buy lots of specialized tools. And it can’t be that providing specialized roles allows IBM professional services to charge a lot of layered rates for different consultant titles.)
• Waterfall methodologies or classic RUP assume teams of specialists. Requirements Experts to gather requirements. Architects to do a big UML design up front. Developers to just follow all the UML and pound out the code. (Oh, does IBM own Rational now?)

I buy the following arguments as being more likely to succeed in practice:

• Generalizing specialists don’t let the project sit there, they just pick up the ball and run with it. If the database schema needs to change they just change it, no waiting around for the DBA. Even though they may not be the perfect specialist to perform a task, by pitching in to do what needs to get done they keep the project on track.
• Generalizing specialists on a project guarantees at the end of a project multiple people know how the system works and can be called upon for maintenance or later enhancements. It avoids silos that kill many organizations.
• Generalizing specialists are constantly learning new things by virtue of not resting on a narrow specialty.
• Generalizing specialists are often good at mentoring or teaching others what they know.
• Generalizing specialists can often converse better with clients and customers because they do things like requirements gathering, testing, or project management even if it isn’t one of their few specialties.
• You can often run a IT project with as few as two generalizing specialist developers. Specialists teams often need a large amount of staff who can’t be dedicated to the one project.
• Agile really doesn’t work without generalizing specialists.

I still require on projects my developers work on that everyone is able to build an entire slice of the system from database to javascript effects on the front-end JSP. Most of them are better in one area or another, but they can all do any of them. I’m really not planning on changing this requirement even if a project involves doing some BPEL.

We have a really good assertive Scrum coach on site. The impact can be felt almost immediately. We had a PM who was learning how to be a ScrumMaster, but she really wasn’t getting any serious feedback on how to handle the nuances of Scrum. One day after our Scrum coach started working with her I got a phone call about 9am.

She wanted to know if we could get some help deploying to our Websphere QA server and who she needed to follow up with. I pointed her in the direction of one our sysadmins. The phone call was no big deal really, but it was the first time for the whole Sprint the ScrumMaster had taken on the responsibility for removing an impediment. Since our PMs are by default put in more of a project admin role, switching to the team protector as ScrumMaster is very different.

The nice thing is with just some feedback from our Scrum coach, this PM instantly became a lot more effective.