The picture pretty much speaks for itself. I haven’t had to make business cards on my own in years, but Zazzle made it pretty simple to do online. I created the logo at faceyourmanga.it. Even in the days of the web a card can have some impact.

Every status report needs to cover the basics like budget, scope, and schedule. Other than that the big thing is to point out new risks or items that have been mitigated. In an Agile context the status reports can often be eliminated entirely, but it tends to be a document people hold onto when getting adjusted to Agile. They often looks like paper versions of dashboards with the traditional red/yellow/green designations. All green means no need to read. Then again I once worked for a director who was actually color blind so I’d make sure the colors are also spelled out.

As a PM I remember borrowing my first status template from another PM who had in turn adopted it from her time at Andersen Consulting (Accenture after the rebranding). I adjusted it, but I’ve used it ever since. I can’t say I have a favorite format for project status reports, but I do know they need to communicate the key points as succinctly as possible. As a PM it’s important to know who’s going to actually read these reports. Some of your audience much prefers to here a verbal update even if it’s very short.

As a manager the best approach to status reports is to stay directly connected with your projects so you don’t need to rely on them. You should be spending a significant portion of time with the bigger projects or the projects that are struggling potentially only relying on status reports for the well oiled smaller projects that are just getting done. And don’t forget to reward those projects that are just getting done right without much need of your services. These are the well managed projects that should be rewarded more often.

Finally, I think I should expand on email and status reports. As managers you typically get 150-200+ emails a day many CCed or forwarded to you as an FYI. When you send that very detailed status report as a Word attachment much of your audience will never read it. I realize PMs often spend a painful 30-60 minutes tweaking the status report to send out every week only for it to go almost completely unread. What I really want is the key points of the status report directly in the email. That means you can send the attachment, but make sure you copy the critical stuff into the body of the email. The pain involved in not being able to read it in the preview pane, having to click on the attachment, wait a few seconds for Word to bring it up and render it just to start reading that nothing critical really happened this week often isn’t worth it. And an email link to the status report buried in project server is rarely any better. So, please don’t rely on attachments.

A few weeks ago at the local Ruby Users Group meeting there was a suggestion of actually writing some code at the meeting. The suggestion was to use a Ruby Quiz exercise. It was quiz #16, a Rock, Paper, Scissors simulation. We broke up into small groups of about three people, coded for maybe 45 minutes and turned in our solutions. My team came in last but it finally pushed me to actually take up a long neglected todo item to start doing coding katas on a regular basis.

I’ve done the classic Bob Martin TDD bowling kata for years as an intro to TDD. I’d also walked through a one day tutorial from a Dave Astels session on Rspec back in 2006 that was very much a game based kata. I’d read about Prag Dave’s coding kata ideas, but I’d never quite found the time to start the practice.

Last week I started utilizing two major resources:

• Prag Dave’s original CodeKata site.
• The KatCatalog from the Coding Dojo wiki.

I’m jumping back and forth between Java and Ruby in the katas to stretch my skills. I may even add in Groovy at some point, but Groovy and Ruby styles are pretty similar. I’m trying to take on one per day and when I wrap around I’ll try out different languages. As a committed TDD student I’ve started each kata with a test. I have to admit RSpec makes this a lot easier when using Ruby and autotest is a wonderful tool. At least I have annotations and JUnit 4+ when I’m doing the katas in Java. For IDE’s I’m bouncing between IntelliJ for Java and TextMate for Ruby. I’m even taking the opportunity to test out git and I setup a github account to store the katas so I can see how I evolve over time.

If you haven’t tried out the practice I might suggest giving it a go. One of the best things is I get to really focus on coding for about an hour a day and it blocks out the rest of the world. Mostly I’m doing them in the early morning to cut down on the interruptions. I’ll probably post again on my observations after a month or so.

I’m now part of 11.5% of all California workers looking for work. My organization decided strategically that they didn’t want to do in-house development, hence they didn’t need a development manager. I just wish I had gotten a longer chance to show the significant quality and cost benefits of maintaining a development team in-house.

There is shock as you realize your routine has changed. It settles down after a few days. Next came the silver lining that comes with this sort of change:

• Doing coding katas every morning to tighten up my programming chops. I’m alternating between doing solutions in Ruby, Java, and Groovy.
• Looking at options to do something I’ve been passionate about like Agile coaching, QA management, or old fashioned professional services.
• Attending some conferences and user groups in the Bay area since I have some travel time.
• Reviewing some open source projects I always wanted to contribute to.
• Catching up with friends in Sacramento over lunch.
• Hanging out with my two daughters including picking them up on bikes last week.

Sacramento isn’t the biggest tech market and it’s home to the state of California government and their massive budget issues, but I’m confident I’ll find a good opportunity.

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.

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.

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.