I’ve heard about git and decentralized version control systems like Mercurial for a few years. Conceptually it sounded interesting, but not compelling. Over the years I’ve used the following version control systems:

• No version control – a very early web startup around 1994. I was blissfully unaware of version control at this point.
• VSS – A horrible experiment in using a Windows share as version control. Better than nothing, but just barely. I’m glad to see Microsoft finally retired this beast with the Team System source control. From the few stories I’ve heard Microsoft never really used VSS themselves and I believe they used to be primarily a Perforce shop.
• CVS – My first love among source control. For months at a startup in Vegas we had to use VSS on servers that were located at the main office in San Francisco. Just listing a directory could take minutes. After a few months of political battles we finally won them over after the CTO learned one of our developers had to fly to SF with a CD because it was the only way to get a medium sized java project checked in. It was great because it just worked. And the speed was wonderful even if it’s a bit slow by today’s source control standards.
• Harvest – They asked us to use this at one client site. They sent out a special trainer to show us how cool it was. The visual client actually used a combine reaping wheat as the animation when you checked in. It took us just a few hours to drop it and just install a local CVS repository and show the rest of the team had to use it. Computer Associates owns the product now which is a sure sign it’s at the very end of it’s life.
• Perforce – Most recently I joined a shop that used Perforce. I had never heard anything bad about it other than it was a commercial solution which meant some limitations on support in various tools. I found it a bit difficult to adjust to the terminology such as ‘client spec’ and other items, but I was pretty happy with it’s speed. It was noticeably faster than CVS. Of course it also caused headaches because it’s integration with various open source tools wasn’t the best. One particular pain point was the Hudson plugin. It turned out some bad decisions had been made in the central repository with relation to directories that contained spaces, despite being hosted on Solaris. Without quoting all the paths the checkouts just failed and the Hudson plugin wasn’t setup to support this.

Early on at the last organization I was leading towards migrating quickly to Subversion. Eventually given the number of contract developers I would impact I put the decision off until some later time. Subversion has great support these days as the CVS replacement, but I knew git and other options were out there. Perforce also didn’t have any critical issues and was easy enough to manage since we had already purchased a number of licenses.

My developers really wanted to ditch Perforce for Subversion. As a developer at heart I completely agreed with them, but given all the challenges on our plate the argument just wasn’t compelling enough from an organizational standpoint. I had a similar recent conversation with our EA manager who asked if we were looking at moving to Glassfish soon over JBoss since we were on a non-Redhat supported version. I pointed out that we had piloted Glassfish recently and were happy with it, but I wanted to wait at least a year to see what the Sun Oracle merger will mean for the Glassfish developers. No one wants to migrate away from JBoss to experience something like what happened with Geronimo.

All the while git in the background git was picking up a lot of traction. I finally broke down recently and purchased Pragmatic Version Control Using Git. Even if it doesn’t end up being the right choice for today and I settle on Subversion for now it would appear the world is headed in that direction in the near future.

As a development manager I relished reading Martin Fowler’s description of values at ThoughtWorks:

• Leveraging bright people over Making the most of moderate people
• Flexible career paths over Well-defined roles
• Delivering business value over Leading edge research
• Learning new technologies over Mastering established technologies
• Solving difficult problems over Increasing market share
• Learning from mistakes over Avoidance of taking risks
• Delivery to the client over Quarterly results

The template is the same as the Agile Manifesto, and it really helps highlight what the real values are by showing them in comparison. Some of them are even daring as they admit to paths they aren’t considering.

Leveraging bright people over making the most of moderate people contradicts the patterns of many IT shops where the model is to maintain a small staff and bring in contractors or consultants for any significant projects. The premise is IT is a service and not core to many businesses so why bother finding the best people. I think this line of thinking is deeply flawed, but what ThoughtWorks is stating is that they intentionally seek out high performers over bringing in mid-range people who can bang out a bunch of hours.

Aligned with utilizing high performers there is an emphasis on flexible career paths, learning new technologies, solving difficult problems, and learning from mistakes. These are the sort of values that are really going to appeal to those high performers. At the end of the day you’re going to have your biggest impact through who you can bring in or recruit to the team. And after dozens of projects over the years Agile, Waterfall, or just cowboy style the best predictor of success was always the quality of people on the team.

Finally there’s a focus on delivering value to the customer over short term gains or cool new research. At the end of the day ThoughtWorks exists because it has clients who need software delivered.

This is a great starting set of values for even an internal IT development group who really wants to envision high quality and performance. It makes writing a departmental charter easy and conveys the critical values in a highly meaningful way.

Recently I’ve been catching up with the Ruby world again in my limited spare time. I had an idea for a fun little hobby project, but I wanted to actually do it BDD style and in Rails 2. I dug a bit into RSpec again and realized they had a new BDD tool called Cucumber. Seeing there was a beta book out from the prags I paid and downloaded the PDF copy of ‘The RSpec Book: Behavior Driven Development with RSpec, Cucumber, and Friends‘.

Cucumber takes plain text scenarios and runs defined steps to verify the scenarios are working. The idea is Cucumber describes the higher level behavior with more of an outside that application focus and RSpec is used to test the behavior of the individual components. There seems to be some overlap, but it modifies the traditional Red-Green-Refactor into:

1. Cucumber: Focus on one scenario.
2. Cucumber: Write failing step definition.
3. RSpec: Write a failing spec.
4. RSpec: Get the spec to pass.
5. RSpec: Refactor.
6. Cucumber: Refactor.

I worked through the tutorial that involves the classic 70s game MasterMind. (I suspect Dave Astels at work there.) I like the textual description similar to FIT/Fitnesse without so many tables. The feature descriptions are in plain English with a few grammatically important keywords:

Next you take the Given, When, Then, And syntax and build out the steps one at a time diving back and forth into RSpec when you get down to the lower level details.

I find the regular expressions a bit jarring, but just like FIT/Fitnesse this is the code that the business users never see. If your lucky you’re testers can read the code and even key off for ideas to use for exploratory testing ideas. The only other item is I always feel more comfortable just dropping back to an xUnit type testing tool and using good practices to give the tests meaningful names and organize scenario testing appropriately. In some ways you could use just RSpec as well for this purpose. Still I’m forcing myself to use it for a while as any new practice takes some getting used to. Next up is integrating it with Rails.

I found myself silently cheering for Uncle Bob as he described a recent presentation where the speaker had just about given up on ever getting better code quality, because businesses didn’t value it.

His claim that crappy code is inevitable is based on the notion that crappy code is cheaper than clean code, and that therefore businesses will demand the crap every time. But it has generally not been business that has demanded crappy code. Rather it has been developers who mistakenly thought that the business’ need for speed meant that they had to produce crappy code. Once we, as professional developers, realize that the only way to go fast is to create clean and well designed code, then we will see the business’ need for speed as a demand for high quality code.

— Bob Martin

Ken Schwaber makes a similar point that dropping code quality to make a date devalues a core asset of your company, the code base. As a line employee you don’t have the authority to even consider making that decision.

I’ve always found this to be a compelling argument for code quality. If your organization has headed down this path for long your code base is a mess. Sacrificing quality for perceived speed to hit a date is a bad practice. Most of the code base is painful even to look at. Maintenance sucks up your limited developer time. There are hidden costs even with new enhancements since small changes can take weeks as a developer digs into the spaghetti code by hand on code that rarely even has the start of a test harness.

The difficulty of course is this is a common method of operation. The PM informs a developer of some date in the future that they need this new critical enhancement. The developer may bravely say that the date isn’t reasonable. More pressure is applied to find a way to make it work. Well, there might be a way let me get back to you.

The developer sends an email a little later explaining that they’ll do their best and they think they can get the feature done. What they don’t explain is:

• To get this done in time I’m probably not going to add any tests.
• I don’t have time to refactor so I’ll probably add more lines to some of the system’s giant classes and mix business logic into the view and controller layer.
• I may have to work some late hours, I’ll be tired and inject new bugs due to this.
• I’ll do a bit of manual unit testing and declare it done well enough to push over to QA. In reality I know it has lots of bugs, but I met the date.
• The next developer who takes on code here will spend even more time trying to figure out the code I added.
• I met the date, but I feel guilty over once again compromising on my own personal standards of quality.

Here’s to hoping Uncle Bob’s vision wins out.

I hopped over to http://rubyonrails.org about 7:40pm PST and found this surprise. After a few tries I confirmed it looks like they there’s a real issue. This is decidedly not what I was expecting. Hopefully it’s fixed soon.