One thing’s for sure (for 2007) I’m learning Haskell. Yeah, that’s right Haskell. Why? I don’t know.

— Charles Lowell of the Drunk and Retired Podcast, Episode 78.

I knew I chose wisely when choosing Haskell.

Many of the practices I’ve introduced to my team have largely stayed within my team. There’s no moat around our section of cubicle land, and all the other teams knew about the majority of our practices, but we didn’t see any uptake. I hoped about a year ago when I ran a TDD seminar with JUnit for the bulk of java developers outside my team that we’d see a change there. About a year later I think the only evidence that they’d been through a seminar on TDD was a few tests scattered across one project.

Osmosis wasn’t going to be enough to convince people. It went the same way with my team. A few of them have really run with everything from code reviews to TDD, but many of them take a great deal of convincing.

The next push was to talk to my peer manager about how we spread the adoption across our groups. I’ve put that discussion off for at least 4 months now largely due to fear. I heavily lean towards consensus building and I don’t like show up preaching like a convert. We’ve had a pretty good relationship though and for some reason I finally stopped mulling over my notes and approaches and just dropped in on him in his office.

Turns out he’s pretty open to the ideas, and it really didn’t take a whole lot of convincing. We’re going to start out introducing some of the easiest stuff like automated builds and continuous integration and then progress to TDD, code reviews, static analyzers and the like. Just one practice at a time so we don’t overwhelm anyone with change. At the end of the process our entire development organization should be performing all the same practices to a lesser or greater extent. By this time next year our basic practices should be shared throughout the development organization.

Definitely should have broached the subject much sooner.

Turns out IBM recently snuck out a way to integrate ruby with Websphere Process Server using SCA (Service Component Architecture). It’s incredibly enterprisey and a bit surprising to see out of IBM. And the whole thing is made possible via JRuby.

Despite the idea of dedicated teams, we really haven’t encountered much in the way of problems with rotating staff on and off Scrum projects in general. Sometimes people come on and off because they tend to specialize in something like UI design and are constantly called out on multiple projects. Other times the work on the project has changed focus or we need someone to start something new. And finally, sometimes someone is just getting burned out an needs a change.

On Scrum teams the main swapping out of resources that gets discussed is when one of the weaker team members is voted off the island for failing to meet any of their commitments. We’ve had that as well, but the majority of our swaps have been for more benign reasons. I have no idea if we’re typical, but rolling people off at releases tends to work really well, or at least at the end of Scrum.

Why SOA Is Good for CIOs

CIOs working with service oriented architecture are at the leading edge of their profession. They make more money, have bigger budgets, have more strategic impact and play a larger role in innovation.

— The State of the CIO Survey 2007, CIO Magazine Dec 2006

Just more self-reinforcing reasons to do SOA. It all comes down to the bottom line. If you’re pushing SOA as the CIO:

Average Compensation of CIOs Working With an SOA

• $250,000

Average Compensation of CIOs Working Without an SOA

• $159,000

My question is can you just brand whatever you’re currently doing as SOA. Then just deploy a web service or two and you’re a leading edge SOA shop? And if that works can you walk into the CEO and ask for a $100,000 raise?