I tend to follow Yahoo pretty closely since my brother and a few friends worked there. (At one point my brother was the product manager for Yahoo Messenger) To a tee all of them got very frustrated with the corporate situation after Yahoo grew up and eventually left. I still get flak about not switching to Gmail from Yahoo mail, but heck I’ve had the same account for at least 8 years.
Anyway Yahoo has been heavily promoting Scrum internally. I found a quote from Pete Deemer, the VP of product development for Yahoo, explaining how they went from a pretty agile, slightly chaotic development environment in their earlier days:
How did Yahoo! get bamboozled by waterfall?
Accenture as experts in a time of trouble.
So for 4 years they did straight waterfall which corresponds to when my brother ranted that Yahoo was losing it’s vision. Probably just a coincidence though.
I think the honeymoon phase for our official Agile projects is over with. The signs are:
- On our first agile project the team got two facing rows of cubicles and a large team meeting room setup just for them.
- On the second pilot the team got mostly moved into the same general wing of one building, but the QA person is separated by about 4 cubes from everyone else as well as the PM. And the business analyst is only dedicated 80% and is in another building. (Maybe the other 20% is dedicated to walking back and forth between buildings.)
- The third Agile pilot is about to start and so far no one has been collocated. I’m working with an admin and the ScrumMaster to find some space, but no one’s volunteering. I’m a little more than tempted to suggest something radical like simply commandeering and squatting in a conference room for the next few months. We’ll have to see if our culture is really ready for that. I have volunteered my office for the team meeting room if they end up in our wing of the building.
- Developer A writes a new test and gets a red bar.
- Developer B implements the code to get to a green bar.
- Developer B writes the next test.
- Developer A implements it.
And of course you’re allowed to refactor where ever reasonable. I hadn’t thought about this in respect to pairing up with my developers as I try to get them hooked on TDD, but it seems a very good pattern for learning how the process works. And of course it becomes sort of a fun competitive game.
I was at a kickoff meeting for one of our officially endorsed Scrum projects this week when a sort of strange question came up from one of the business owners:
So no one wants to get assigned to this project in my group because if you’re on a Scrum project you can’t take vacations.
This was pretty easily dispelled with an explanation that vacations are allowed including surprise things like people getting called out for jury duty. Basically backed by two of the Agile Manifesto Principles:
- People over Process
- Responding to Change
It does however exemplify some of the rumors that crop up when you start a new process like Scrum. The biggest thing that shakes up a lot of our organization is the idea of collocating and the idea of dedicating staff 100%. My sense is it’s turf protection stuff, but it could just as easily be fear of the unknown.
Listening to a podcast by Tim Shadel on difficulties with JSF and why he wouldn’t use it again brought up a current headache in the java web development space. Today’s options for java web frameworks blow.
Let me expound a bit:
Struts – Works fine, has been the defacto standard for years, but its showing its age. It hasn’t really been updated significantly in years. It doesn’t have an obvious successor yet since there is no Struts 2.0. It’s harder to test because it extends from all the framework classes. Within the java community it’s considered pretty much a legacy framework.
JSF – Very hyped and part of the J2EE spec so it’s supported by the app servers. Has a lot of vendor tooling support showing up. Has a very flexible event model. Is being pushed by the creator of Struts. Unfortunately it suffers from a host of problems. Tim Shadel described just a small part of this his recent post on JSF. Essentially he described how they had to get around JSF’s lack of handling GET requests with a few URL parameters.
His example was having one WAR file that needs to link to another WAR file and pass along an id. The hack involved:
- Creating an extra JSP file.
- Linking to the JSP file directly.
- Send along the parameter.
- Opens up FacesContext.
- Gets the request object.
- Pulls off the id parameter.
- Locates a backing bean with session scope.
- Stuffs the id the backing bean.
- Forwards it to a JSF page.
- Then it can pull up the appropriate page and get the parameter.
This is just plain ugly. Tim goes on to mention that when someone waxes grandly about JSF he asks a simple question? So how do you write a blog in it?
I still have some hope that JSF may evolve to something reasonable, but today it’s still pretty messy.
Tapestry, Webworks, Wicket, Spring MVC, etc – I haven’t spent much time with any of these web frameworks for a simple reason. They don’t have really a large enough mindshare and community to make me think that betting the farm on them isn’t a huge risk. I have no doubt they are probably all better than Struts, but none of them have really caught on as a Struts successor.
This is exactly the reason why something like Ruby on Rails has so much appeal to java web developers since in Ruby it’s by far the defacto standard for web applications, and it includes lots of cutting edge features from built in unit test harnesses to AJAX support. Since JSF doesn’t appear to be the hoped for Struts replacement I wonder if we’ll see one anytime soon.