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.

On a whim I setup a Google App Engine account and an hour later I had the hello world Groovy example up and running. They recently added a Java option to the current Python stack. I pulled a quick tutorial from Guillaume Laforge on launching a Groovy web app. A few downloads and a bit of configuration and the app was deployed. Pretty impressive, especially for a free place to do Groovy deploys. The real fun will come when you can just dump Grails apps directly up there.