I’m about halfway through Michael Feathers’s Working Effectively with Legacy Code, and I came across his attempt to handle nasty methods that take multiple parameters by merely passing in nulls and seeing if the test will still run. If the nulls are good enough then you can spend a lot less time digging through the legacy code for knotty dependencies. I’ve tried this before myself, but I never put much thought into it until I ran across it here. Pretty interesting read so far though I find the C++ code examples a little hard to follow sometimes.

I got blindsided by some consultants today explaining that we would be implementing SDO for our ORM layer. I’d barely heard of it and it has almost zilcho profile in the general J2EE community. Apparently I’m being overruled by said consultants.

So I did a little 10 minute research on service data objects versus Hibernate:

• Number of books on Hibernate on Amazon.com: 8
• Number of books on Service Data Objects on Amazon.com: 1 (An IBM Redbook)
• Number of jobs on Monster.com listing Hibernate: 373
• Number of jobs on Monster.com listing Service Data Objects: 1

Jeff Sutherland covers the familiar Scrum metaphor about pigs and chickens:

I got kicked out of the pig pen today! We just started our first official Scrum project today with the first day of the Sprint. Unofficially I’ve run two Scrum projects already though I’m working more from book/blog knowledge than deep experience with Scrum.

We have a fairly knowledgeable consultant on hand coaching us on the process. The best thing of course, the whole reason you hire consultants, is that she has a lot more experience than we do with Agile methodologies with several large clients. So I’m pretty desperate to get any help I can get, especially help we’re paying for.

I sent a friendly email to the Scrum Master for this pilot project asking if I could attend the daily Scrum with one of my employees as chickens. I was very explicit that we would just be observers hoping to pick up some tips and tricks, and that we would probably only attend 1-2 per week. After about 4 hours I got an email back explaining that it was the Scrum Master’s role to protect the team from distractions so they don’t want us to attend since the team is very fragile. Clever argument since it is a central role of the Scrum Master, too bad we hadn’t proved we would disrupt the team in any way.

I think our organization has a long way to go to get Agile. Right now we’re too scared to share.

My team has been running automated builds pretty for well over a year now on at least one project, but the bulk of our projects weren’t being built on any regular basis. I’ve been gently introducing the concept and adding all our current projects to the build cycle. This is the week where we jump in fully. Tomorrow I have a short Keynote presentation to the team explaining cruisecontrol and how it works on our little build box. The message is essentially faster feedback and faster failures is a better way to build software. I’m interested to see the feedback I get tomorrow when I present this at the weekly staff meeting.

This Friday despite spending the entire day firefighting some production deployments I got pulled aside into a twenty minute or so discussion with three of my developers. They were griping and asking about what they needed to know for their next projects.

The bulk of them have learned Java within the last year, Struts, iBATIS, JBoss, ant, IntelliJ IDEA, and JUnit. So they’re a bit tired of picking up new technologies and are just becoming profcient with the current set. The problem is management is asking them to learn the Websphere toolkit:

• RAD 6.0
• Portal and Portlets
• JSF
• Websphere Application Server
• Attunity (a SQL interface to Natural/Adabas

They’d all just gotten out of an IBM RAD class which wasn’t bad, but apparently the labs were just step by step demos and not very challenging. ‘Something a trained monkey could do.’ Anyway all of them were a bit overwhelmed with all the options in RAD and confused as to how it was going to really make them more productive.

I did the best I could to explain my personal philosophy that I pretty much agreed with them. Adding much more than one major tool or framework per project was a bit much to be expected. One of them explained that they could code something in JSF, but they just now were feeling comfortable in Struts, so doing it in JSF would take much longer.

So now I’ll go back to upper management to explain the craziness of adding so many tools at once and expecting reasonable productivity. My personal agenda is to greatly expand our use of unit testing with growth in refactoring and design experience to follow from this. Just tossing new tools on the heap doesn’t seem to help. I’m afraid though the push to use the expensive shiny new tools will override the fairly obvious logic. Sometimes you’re sort of like a second lieutenant in Vietnam as a line technical manager.