Ted’s Rants and Raves by Ted M. Young

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.