Tim Shadel has a post entitled, JSF: The 7-Layer Burrito I Won’t Eat Again, and podcast on his experience with JSF. I’m guessing the 7 layer burrito comment refers to the 6 lifecycle phases in JSF. Anyway I’m eagerly awaiting to get to this podcast on my iTunes playlist. Tim’s vote on JSF after his team has used it for about a year, “Skip it.”

Our experience has been pretty mixed with JSF. We’ve had trouble finding decent books, trainers or resources despite the hype surrounding JSF. Out of six developers on our development teams that have actually used JSF on a project I get:

• One positive vote.
• Two less positive votes with a lot of caveats.
• One neutral vote.
• Two very negative votes.

If I had my choice I would still be adopting wait and see on JSF, but some consultants were pushing it so it became a non-functional requirement on some new projects. I think JSF may prove out, but it could just as easily go the way of EJB entity beans.

Technorati Tags:

software development, podcasts, jsf

Listening to episode #16 of Code Sermon this week the, the host made an editorial comment about a trend in podcasts having a couple of minutes audio intro.

It seems like filler and I don’t think we need filler in this new medium.

I’ll have to second this. The point of podcasts is the content. I don’t mind a short audio lead-in as a way to brand a particular podcast, but beyond 20 seconds or so it just starts to seem excessive.

Some podcasts also tack on a podsafe song at the end. This is less of a problem as generally I just skip ahead to the next podcast.

Technorati Tags:

podcasts

Scrum and XP and indeed many of the Agile methodolgies value the idea of from XP of courage. In Scrum this is the ScrumMaster bubbling organizational problems to the surface and trying any reasonable tactic that won’t get her fired to resolve the issue for the team. In the Agile Manifesto it’s People over Process.

Today I successfully applied this idea by reexamining a problem I thought was beyond my control. The issue revolved around sending one of my developers, Ian, to an internal use case training course that we’re offering. The history of this effort:

• Ian asked for some use case training 1.5 years ago due to a professional interest around requirements gathering. I asked Ian to research possible classes.
• A class was arranged, but cancelled due to low enrollment.
• We brought in a coach/mentor to do some Agile training including a two day Use Case class about 7 months ago.
• A use case class was arranged in September, and I was assigned to attend despite being pretty proficent with use cases.
• I argued that I would go so that I understood how we were implementing use cases, but I really wanted Ian to get a slot. Ian didn’t get to attend the class, but there was supposed to be a second class.
• There was a second class in November, so I asked if Ian could attend this time. It was explained to me that there might be some open slots, but no promises. Ian again couldn’t go because there weren’t any open slots.
• I had Ian research Use Case courses available even if it involved travel. He found one in San Francisco by the coach/mentor that we had hired and their company and another one by a different company in Boston.
• He talked to our coach/mentor about attending the training, but she explained that the class was being cancelled due to low attendance.
• In the meantime Ian researched and found training in January for ScrumMaster training in San Diego.
• Then in late December two of my developers were assigned to an official Agile project and signed up for Use Case training with the coach/mentor.
• I again made the case that Ian should be added, and I got the feeling that there were open slots this time, so on the fly Ian had to switch the ScrumMaster training because it was on the same dates as the Use Case training internally.
• Following up on the Use Case training slot for Ian I was told that spots were being reserved for other organizational groups. I explained the whole history of trying to arrange this one class for Ian, and got the promise that if there were empty slots that Ian could have one, but no promises.
• I calculated that if we had to send Ian to Boston for the same training that it would cost the company about $2000-$3000 versus almost free since the coach/mentor doing the training is being paid on a billable hours basis. As a business decision this seemed obvious.
• I didn’t get any answers about whether Ian could go or not this morning so I sent him over to the class.
• Tomorrow Ian will successfully complete the Use Case training class finally.

I may have to deal with fallout from this action, but as a manager trying to remove impediments I’m willing to take a little bit of heat. And it’s good to reexamine your assumptions every so often. If I had just waited to be told there were no slots again Ian would still be waiting and we may have had to spend $3000 and send an employee across the country just to get training we’re offering internally through a very capable trainer.

Technorati Tags:

management, software development, scrum

Despite the enjoyment I get from doing development or even working through a configuration or installation issue I often find that I have weeks like the last one. Last week I was unable to code at all either at work or at home. Work was just a series of firefighting exercises largely to get to new projects deployed and at home I spent my few free hours coding and catching up on some old household todo items.

I’ve accepted that my job as a manager is largely to develop my people. Still, I realize that most technical folks will quickly lose respect for you if your technical skills wither substantially. My compromise has always been to devote myself at home to doing a lot of learning and coding. This week was just one of those where I didn’t get time to fire up an IDE and work through some more unit tests while learning Ruby.

Balancing technical skills versus management skills is something I expect I will probably always struggle with and is just part of the territory. I’m just glad I really enjoy both or the balance would get out of whack in a hurry.

Technorati Tags:

management, software development

I’m making my way through the Snakes and Rubies presentations of Django and Rails. One thing that surprised me a bit was that both Adrian Holovaty and David Heinemeier Hansson both came out of a PHP web development background. Within these presentations both explain that PHP was so messy that they developed their frameworks in Python and Ruby so they could write beautiful code.

Given that there’s been a lot of attention around high profile java developers jumping over to Ruby on Rails, I was a bit surprised to see a migration from PHP as well. I’ve actually been in web development long enough to remember that PHP stood for Personal Home Page. I migrated to Java from Perl and really enjoyed Java’s static typing and the wealth of libraries that have developed. Long ago though, I did a lot of Perl CGIs. So I guess it shouldn’t really surprise me that when PHP developers go looking for new pastures that they Ruby on Rails is an obvious path these days.

One nice side effect is that some of this is leading to PHP developers being exposed to better engineering practices like unit testing. In a recent Ruby on Rails Podcast, Scott Raymond, a longtime PHP developer, explains how he had heard about XP and unit tests, but Rails made it so easy that he started actually writing them and improved the quality of his code.