I keep hearing that Scrum’s name comes from rugby, that a rugby scrum is a great model for a self-organizing, adaptive software project following the Scrum methodology.  (Note: I’m in a scrummaster training course today and tomorrow, am a practicing scrummaster, and also played and coached rugby for many years.  So, I’m qualified to rant on this particular topic.)  But the scrum is the least self-organizing and adaptive kind of play in rugby.  Here’s what a scrum is: it’s akin to a kickoff to restart play after something’s screwed up the normal flow of the game.  It’s a set piece, with each player knowing their position and standing in the same place each scrum, trying to do exactly the same thing each time.  When I coached, it was important to me to teach proper repeatable scrum technique because if anyone doesn’t do their part or somehow changes the formation, someone can get seriously hurt: necks get broken in poorly formed scrums.  So, that’s what we say our software processes aspire to: a play you use after someone’s f’ed up the normal flow of the game, where each person does exactly the same thing every time, in which a failure to conform can break someone’s neck.

Now, there is a rugby play which is completely self-organizing and adaptive.  It forms to continue play when the ball’s about to change possession.  Say I have the ball, and I’m about to get tackled.  I want to get the ball out to my teammates so I turn around to give them a chance to get it (rather than have the other team strip it away from me).  I fight like mad to stay on my feet and let my team get to me, at which point they’ll start piling on in a proscribed sort of fashion, but driven by whoever’s nearby and can get to me fastest.  The number of folks involved and amount of pushing depends on how much force the other side musters, and whether my team can get the ball away more quickly than the other team.
Now the problem is the name of that play: it’s called a maul, which understandably might be a bad nom de plume to attach to your software project.  In nearly as bad a naming situation, it’s companion play is called the ruck.   That’s when I don’t manage to stay on my feet, but end up tackled and trying to protect the ball on the ground with my body.  There my team doesn’t just shove me around, they actually step over (though hopefully not on) me to push back the other team and retain possession of the ball.  However, I’d still rather compare my software process to a maul than to something which my team would do when someone on either side screwed up and stopped things from progressing.
I’ll end my rant now, with the additional noted rugby qualification that, in true rugby style, all rant listed above was influenced through the imbibement of beer.

I noted in a previous post that I was changing jobs, hopping over to the Java side of the fence.  Note that I had spent the past two years building enterprise Microsoft .NET systems, so this was something of a change of pace.  Not that I hadn’t done Java before: before those .NET 2 years, I was building Java systems for a government health research project.  [Noting a habit of mine to change technologies, and to use the word ‘note’.]

More than a month into the new job, it’s a good time to take stock of what I’m doing, and what the surprises have been:

1) Knowing Java is no longer enough.  To accomplish things in Java, you seem to need to know a large variety of frameworks or open source projects.  On our project, we’re using AppFuse, Struts, Tiles, Hibernate, IBatis, and Lucene, just to name a few.  (Trust me, there are more.)  Note that while I could have told you what most of those do before this job, I had little-to-no hands on experience with any of them.

2) The toolsets used are radically different than my experiences in Visual Studio and SQL Server.  Eclipse and Oracle are the tools of the day, with a hearty dose of Ant and CruiseControl.   Subversion is also a different beast than was StarTeam, PVCS, or Visual SourceSafe.

3) Unix administration background is a big plus.  Although our local dev environments are Dell laptops, our development server uses RedHat SE.  There’s no handy EventLog pane in a Unix environment, and vi has become my friend again.  I generally get out of the way when there’s a real admin problem, but have reminded myself how to do some rudimentary administration stuff, and can sudo with the best of them now.

4) The set of unit testing tools is much more comprehensive.  Sure, we have JUnit, but then we have StrutsTestCase, MockJ, and Canoo, too.

5) Oh, forgot to mention Spring.  Its pattern of bean injection is cool, so long as you set up your context files well, but I haven’t quite got the hang of its AOP logging.  I’ll remention AppFuse, too, as the way it generates many things causes some learning curve in and of itself.  Think you’re looking for struts-config to put your info in?  Welp, AppFuse makes use of XDoclet to generate that struts-config, so it doesn’t actually exist in your source tree, only in your generated build output.  AppFuse also uses XDoclet to generate your database schema, but XDoclet only goes so far in that task.  To actually do things like set up a database index or set a start value on a sequence, you’ve got to do some monkeying around with the build process.

6) Eclipse is cool.  It deserves a post all on its own in the labor-saving stuff I’ve been able to make use of, and I’m certain there’s more I haven’t yet tripped across.

7) “Tripped across” is a good metaphor occasionally for how we end up solving problems.  Trying to figure out how to do something with Acegi, I go wandering the forums and the blogs and the Wikis trying to find someone who’s done something similar to what I want to do.  Bam!  Got it!  It’s something that’s got supported classes in the jars I have locally.  But that stuff wasn’t even mentioned in the documentation, other than in the javadocs, and the javadocs of course don’t tell you how to actually use the stuff, just what to pass into its methods.

Think that’s enough for now…  given the amount of I’ve picked up over the past month, you’d think I hadn’t gotten anything else done besides wade through documentation and code.  But we’re (and even me – turns out no one has complete experience with all of this stuff, so we’re all picking up some amount of things) actually getting stuff built pretty quickly.  And quickly it has to be..  only some 70 some days before Alpha!

If they’d only had Barbies like this when I was growing up: http://www.b3ta.com/board/4577623  (originally seen on Wired in its gallery of weirdest USB devices )

I’m working on a survey application here at work. Nothing amazing, but it’s been interesting to start with something of a clean slate. You realize just how many things you do just because you’re used to doing them that way.

Things that have occurred to me to try, or to investigate on this thing:
– Should this really be a web application? Would it make sense to have it show up as a form in Outlook, such that the user never even leaves the email that requests them to fill out a survey?
– Would it make sense to use some of the Enterprise Library Blocks for security, caching, data access, etc, from Microsoft’s patterns and practices area, rather than custom-writing authentication and authorization code for this simple application?
– What about setting a template project so that Chris can hand it to his development team and say, here: out of the box security, logging, etc.?
– What about using an ORM tool, like NHibernate, rather than hand-coding a bunch of data-access layer code? If you do that with the data access block, though, you’d have two different data access idioms in use in the app: probably problematic for someone else to have to maintain. Probably the NHibernate thing itself would be problematic, in terms of other developers later maintaining…

All things to play with, though probably less than I’d like. Just need to get a basic survey app up and running – nothing too key here. But still would be nice to evaluate these other things and make recommendations for use here….

Thinking through all of the “non-trivial”, “orthogonal” change requests our client regularly gives us:
Xooglers: Word

So, you wanna pay us for CR 3456 or what?

Laughed my rear off, at myself for thinking this “love story” is funny: DotNetSlackers: A Design Patterns Love Story ASP.NET News

Interesting bug for the day: .NET .ASPX referencing a namespace that the project can’t find. First check: did the set of referenced assemblies for the project change? Nope. Second check: did the .ASPX itself change? Nope. Hmmmm…. the namespace just… disappeared.

And Penn and Tina reveal the magic… a namespace doesn’t exist in and of itself. It only exists as classes claim to belong to it. So, when even one class changes its namespace, if it was the only class that laid claim to belonging in that namespace clique, the namespace just disappears.

Makes me think of Tinkerbell in Peter Pan: so long as you believe, it’s still there. And as soon as we stopped believing, the app became non-functional with a set of run-time compilation errors. (Of COURSE that one referenced namespace was by default included everywhere, just in CASE it had some functionality you were going to need.)

Pixie dust… Pixie dust… where’d I store that Pixie dust?

Holding onto this “snippet” of code (6200 character Perl regular expression) for the next time a user gives us a requirement that “all email addresses should be validated”: Mail::RFC822::Address