Ted’s Rants and Raves by Ted M. Young

I’ve been reading lots about Kanban ever since David Anderson talked about his experience at the Nov 3rd (2008) BayAPLN meeting. On the Kanban developer email list, a new book on the topic was announced, "Scrumban", so I immediately went over to Lulu.com and purchased it. I’ll probably start reading it next week as it’ll be pretty quiet in the office.

In the meantime, if you’re at all interested in (or practicing) Agile, I highly recommend also reading about how Kanban is being applied to software development. The email list is a good place to start, as is David Anderson’s blog and articles.

This morning at Code Camp, Shaun Abram (http://www.shaunabram.com/) asked me about my "Building Better Tests in Java" presentation where I talked about using Test Data Builders instead of Factory classes (what we at Guidewire call DataGen classes). He said that he liked Builders, but wasn’t sure what the compelling benefits were. I’m glad he asked because besides giving me an idea for a blog entry, it’ll make me go back and make it more clear.

If you were at the presentation, here’s the reasons that I had hoped to get across:

• Prevent the combinatorial explosion of variations on methods to create an entity. In one example, we had 12 different variations to create a Policy. Yikes.
• Tests become much more readable. For example, would you rather read:

Activity myActivity = DataGen.activity( true, true, false, true, true, Status.NEW, Priority.MEDIUM, false );


or, with a test data builder:


Activity myActivity = new ActivityBuilder()

        .autoGenerated()

        .notEscalated()

        .ownedExternally()

        .mandatory()

        .recurring()

        .statusNew()

        .priorityMedium()

        .shared()

        .create();

If you said the first one, you’re far too familiar with our Activity entity and probably work at Guidewire.

Shaun also mentioned a problem where someone comes along and changes one of the defaults (i.e., the value of a property that wasn’t specified) in a factory method to fit the test they’re writing, only to break a bunch of other tests that relied on different defaults. They probably did that because they didn’t want to create yet another factory method that took the property as a parameter so they could choose a different value.

Also, Jeff Brown (http://blog.bits-in-motion.com/) at the BBQ last night mentioned that he was surprised I didn’t use the phrase "fluent interface" and he’s right! OMG! There goes my credibility. Seems like a need to rework my Builders presentation, but I think I knew that.

If you’re looking for slides and other information from my Silicon Valley Code Camp 2008 talks (either Easing Into Agile or Building Better Tests in Java), stay tuned! I’ll be uploading them very soon!

Thanks for coming!

I was just reading Per Olesen’s blog entry about Adobe Flex and the fact that it’s closed source and proprietary, and it hit me that the reason I haven’t tried Flex is because the source isn’t available. I remember years ago at eBay when we were using C#/ASP.NET 1.1 for internal web app development and it was so frustrating because when an exception was thrown inside the framework, you’d hit the “no source wall”: the place where the stack trace leads you to code that you can’t look at. At least in the Java framework I can trace through the code and even set breakpoints in framework code so I could figure out if it was my code’s fault or a bug in the framework. Usually it was my code, but whereas in Java I could figure out what I was doing wrong by looking at the Java framework code, in ASP.NET I often just gave up and tried a completely different way of solving the problem (usually by tossing out the use of ADO.NET). Sometimes I even went to the Mono source to see what they’re doing and it did help when I was creating ASP widgets, but it’s not the same thing as having all of the source available with the ability to step into it in a debugger.

I haven’t followed .NET development much since I left eBay, but I’ve noticed that Microsoft has opened up some of the .NET framework source, which is definitely a move in the right direction.

So, I guess subconsciously I’ve been staying away from otherwise appealing frameworks if I can’t access the source code. And it doesn’t have to be “open source”, as in GPL, LGPL, etc., but I at least want the option of seeing it if I need to. I don’t mind proprietary, but without the source, I’m going to choose another framework, my time is too valuable to hit my head against the wall otherwise.

I use a piece of software that’s currently going through a beta period for it’s next release. It used to be that there was a new beta release every couple of weeks, but then that was reduced to every month. This was fine with me because I often didn’t have time to install every new beta. However, the second beta had some serious problems and so I had to return to using the first beta. One month after the second beta, there’s still no sign of the third beta and the natives (users in the support forums) are getting restless.

The reason for the delay? The developer decided to switch to the latest version of the IDE/Language/Framework and some of the third-party components being used aren’t compatible. So now the developer’s in a bind and has to either fall back to the previous version of the framework, or try to get the problems with the third-party component resolved. This means another several weeks or more will go by before things are stabilized enough to put out another beta.

The moral of this story is that while you’re in the beta cycle, you should minimize the changes to your tools (IDEs, frameworks, components, libraries, operating system, etc.) so that you can focus on getting your product out the door. Doing otherwise is like trying to add a turbo-charger to your car’s engine while you’re driving.

On the other hand, sometimes you need to upgrade one of your tools because of a bug fix or a new feature that you really, really need (this is more like pulling over to the side of the road to change a flat tire). In that case, change only one thing at a time — don’t try to change other tools just because you’re already on the side of the road: that’s no place to be doing major overhauls. Wait until the next release when you’re safely in the garage and have the time and tools to ensure that you can do a quality job.

Test-Driven Development or Test-First Programming, or whatever you call it, is a way of programming where you create the test code before the production code. There’s a new push for doing this here at Guidewire, and I’m looking forward to doing more of it and talking about it here. In the meantime, I’m reading the early access of "Test Driven" by Lasse Koskela (you can pre-order it at Amazon). I’m hoping to see more of a focus on the "customer acceptance" part of test driven development, so we’ll see how that works out.