Read through a few posts over on the Subversion site after someone pointed to it. So apparently VSS will finally follow the Dodo bird off a cliff. It’s about time!

VSS had always been an amazingly bad version control system. I worked for an ecommerce dotcom back in 2000 where VSS was the default source control system. After one of our uber developers wrote his own proxy service for a client with about 500 classes he tried to check it in. Since VSS assumes it’s on a local network share and we were actually on a VPN with limited bandwidth to the corporate office in SF it took 8 hours and failed on the initial attempt. Just getting a directory listing in VSS took minutes sometimes.

Anyway after he had to fly out to the SF office to successfully check it in, the company considered moving to CVS. The final nail in the coffin were the explanations from our handful of ex-Microsoft developers. As one of them put it, “Oh, we never used Source Safe at Microsoft, it doesn’t scale.”

I got around to downloading and running a Hello World example with Dave Winer’s OPML editor which has now been ported to the Mac. I like outliners in general, and there seems to be some promise this new outliner.

Anyway these are just first thoughts:

• The OPML icon is ugly and pixilated, typical developer stuff.
• The directions assume there is only a Windows version after step 1. Instead of the saving the first document to <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

  1	C:\My Documents\OPML\www

  </div>

  it should go to

  1	/Users/edgibbs/OPML/www

• After creating a test outline and looking at it in a browser, I’m not seeing any magic, but heh I only spent 10 minutes tops.

Now to look at the Instant Outliner functionality. Dynamic outlines shared among a project team, interesting idea.

Before I came onboard at my present company I was fairly impressed with their use of a rules engine. It seemed better than most places that on a major application they had tied all of their business logic into the rules tier, theoretically for reuse.

Of course you don’t necessarily see reality in an interview. The realities included:

• The rules engine was brought in house to solve the problems with a wonderful ‘Big Bang’ project.
• The rulebase had a few thousand rules organized into rulesets, and then we implemented workflow, or ‘rule flow’ in the rules engine.
• The software was so expensive we only had a few licenses for developers, and only two developers worked with the rules engine product at all.
• Debugging the rules engine is difficult, and unit testing it is a nightmare.
• And finally the business analysts were supposed to write the business rules in the tool. I’ve never seen this work where the programing interface is easy enough to use for the business side. Lots of tools promise it, I don’t know of what that delivers it.

One of my developers is looking into Drools, after a brief look it appears to be a much better match for our requirements.

Another example of a simple rule I try to follow, ‘Always avoid Enterprise Software where possible.’

I came across a slightly more detailed explanation of how to write feature titles in FDD, basically:

<action><result><object>

So an example would be, Add an Item to the Shopping Cart or Calculate Total Registrations for Class. Having just gone through an exercise of planning out some features and estimating ‘story points’ on a project, this makes a lot of sense. It seems to reinforce that they are small task level items instead of things like full Use Cases such as Manage Customer Orders or Build Giant Report. I’ll have to try this out with the next Scrum product backlog list I develop.

Listening again to a Polymorphic Podcast while I was out strolling around Sacramento at 5am on my morning walk, I heard commentary that struck a chord. The person being interviewed on the show was Kent Alstad, a developer with 20+ years of experience, who’s published a book or two in the .NET space. When asked about how he had adopted TDD he started to fumble. His best answer was that he felt guilty about it, but on his most recent projects he hadn’t done that much actual testing with NUnit because much of the application was in a GUI, ASP.NET I would assume, and when it became hard to test, the testing got dropped.

This seems to be a continuing pattern of anecdotal evidence that I’m collecting. I see it in my own organization with my bleeding edge developers who walk and talk unit tests, automated builds, etc, but let CruiseControl fail for weeks at time. I see it interviewing developers, who to a person have at least JUnit on their resume, but then admit they haven’t written a unit test in 2 years, and can’t remember how JUnit is organized. And finally, I see it in myself when I sit down with a developer to tackle some issue, but I rarely have them write a test, because we can solve the problem without it and they don’t even have any tests in place to begin with.

So right this moment I feel one of my greatest failings has been getting my developers to adopt TDD, but I’m beginning to think I have a great amount of company here. The understanding of TDD is fairly wide, but the adoption in many shops is shallow enough for my 1 year old daughter to feel comfortable in.

I’m still highly convinced it’s the right path to go down and the benefits outweigh the costs. It’s going to be harder than I thought, but if we can adopt TDD in our shop we’ll jump to the head of the pack.