I took an opportunity to head down to OSCON a week or so ago on a free expo pass. I always wanted to attend OSCON up in Portland, but I never had the opportunity to go. Anyway I invited another developer along and made the morning drive down to San Jose amid unusually light traffic. Reminded me of the times I drove around during the dotcom bust.

As an expo attendee there were a number of free things to do beyond walking around looking at vendors. The bulk of these involved attending OSCamp which initially looked sort of like it might be an Open Space type offering, but ended up being more of a loosely organized mini conference. I listened to three different speakers.

Bill Shupp from digg.com gave a talk on the PHP PEAR proposal process works. The key takeaways were that it helped to bring PHP coders into a more formal process where you follow some coding standards, are expected to have unit tests, and go through a code review process. He explained that digg.com had really gotten into unit testing and TDD including hiring the author of PHPUnit to help them with the adoption. They are also running a CI server and a nice 52 inch monitor with red or green for each currently running sprint.

I didn’t catch the name of a speaker who explained how he got into open source through the PHPbb bulletin board software, but it was nice to see a high school student who really felt empowered by contributing to software that’s used by thousands of sites.

Marcus Westin from Meebo gave a talk on Javascript best practices which included a mention of HTML 5. It was compelling enough to make me think I should look into it. Meebo is essentially a giant javascript application and Marcus explained that he’s a full time Javascript engineer. I hadn’t really thought of the idea of full time javascript developers, but Meebo is actually hiring even in the bad economy. He talked about how they’d been cleaning up the codebase over time, but there was still some 8000 line Javascript file that was too hairy to refactor. Sounds like a great challenge to get some test harness around.

Overall I enjoyed the free expo day at OSCON, and if I get the chance to be sponsored by my employer in the future I’d put it on my short list of potential conferences.

About half my career has been inside professional service firms. The work has quite a few perks and you’re constantly pushed to learn new things. Having spent quite a bit of time within IT departments as a manager I did sometimes missed the wealth of different clients and projects you’re exposed to as a consultant.

I’m not sure how common the practice is, but after leaving my last professional services firm about five years ago they let me know they considered me part of the alumni network. I remember thinking it was a novel way to approach employees who leave your company on good terms. I’m not sure how common the approach is, but I think it pays significant dividends. Over a few years I got a few little goodies in the mail including a USB key at one point and I ended up doing a few very short engagements to help out the local office.

For the professional services firm this sort of practice is a little extra effort, but pays particular dividends:

• You maintain a good relationship with former employees which helps in a small way your overall brand.
• Those employees may send prospective new employees your way who are already well recommended.
• Former employees may need some professional services and you’re often invited to compete for work.
• The alumni member may throw some leads your way when they find out about potential projects.
• Those alumni members may someday return to your firm bringing back valuable experiences from their time outside the firm.

As I now find myself returning to the fold with my former firm, I’m impressed with the little extra effort they took to stay in touch.

Unit testing is a practice that takes years to sink in. For many the first experience with the green/red bar is interesting, but not life altering. Maybe it was just a quick demo. They go back to the normal debugging patterns in the IDE or with printing output to the terminal. They try testing for a bit and find battling with legacy code just doesn’t feel like its worth the effort.

How do you effect change here? After experience with several groups I’ve found a gradual approach to work better than total immersion:

• Exposing the team to the concepts, especially if they haven’t really seen a true TDD session.
• Explaining the benefits to them as developers with reduction in defects, better code that’s easier to refactor, and knowing that when you get asked to work on a legacy codebase with a decent test harness that you won’t have to cross your fingers that the new feature you added didn’t break some other code.
• Continuing the conversation through one on ones and other means of how testing is going and where they’re having trouble writing tests or how writing the tests first might work a little better, or even starting with just some larger integration tests. With one team I asked the question of all the developers every week, ‘How many tests did you write this week?’
• Celebrating as code coverage metrics start climbing and pointing back at the reduction in defects.

While I often hoped the process of becoming real TDD style developers would take people a few months, it often took years. I never saw overnight success with adoption, but after time I started to see ‘aha’ moments among many of the developers:

• A developer who was dedicated to testing let about 20 unit tests start failing because he’d made some changes to the domain model. He knew he needed to get back to them, but had prioritized some other work. As the tech lead on the project who I’d worked with for years saw the failure email from the CI server he rushed over right away and got the developer refocused on fixing the tests first.
• Another developer finished off a recent project release and had zero real defects. The code coverage was well over 80% and among the best tested code in the organization. I’d started introducing testing to that developer over 6 years ago, but now he feels bad not writing tests.

As a manager and a person I treasure these stories as I hear them even if it they were years in the making. They’re more important than any kudos on an annual review or a big end of year bonus.

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.

As a project manager on dozens of projects I have sent hundreds or perhaps thousands of project status reports. I’ve read even more status reports as a development manager often showing up Friday afternoons in the old inbox.

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.