This week I started fresh with a new company and a new title. After four years as a Software Development Manager and a short stint as an Enterprise Architecture Manager I’ve now returned to managing a group of internal IT developers. The current title is Application Development Manager.

The new organization is full of opportunities and challenges. Some of these include:

• Inheriting a senior development team.
• An organization which is still early in the process of formulating practices and process.
• High level support for process improvement a mix of CMMI, ITIL, PMI, and a bit of RUP at present.
• Systems with real high availability requirements.
• A JBoss shop.
• A QA team pushing hard to push for quality throughout the project and not just at the end. Plus they’re doing automation and load/performance tuning.
• Developers self-organizing a weekly gathering to discuss software topics.

I wake up about 5 am these days to go for a walk every morning. These days it’s a lot easier to bounce up and not just hit the snooze button. If I can get Perforce setup with a Hudson plugin I might just set up a continuous build box tomorrow.

A sense of fun can help new practice adoptions. After reading a post by Clint Shank on coming up with a continuous integration game Erik Ramfelt went ahead and created a Hudson plugin.

Currently the points you get are:

• -10 points for breaking a build
• 0 points for breaking a build that already was broken
• +1 points for doing a build with no failures (unstable builds gives no points)
• -1 points for each new test failures
• +1 points for each new test that passes

Looks like a good starting point. I really like the idea of getting points for implementing new tests.

As a manager of developers I have a goal of trying to provide at least one week of training per year at a bare minimum. For senior developers or even journeyman developers in transition the best available option is often a conference. The benefits far outweigh the costs:

• Exposure to software development outside of your small corporate IT shop. I know people read blogs and books about software, but talking to real people can bring the message home. I had been evangelizing things like TDD and continuous integration among my developers, but when I sent four of them off to a conference they all came back saying, “Wow, this TDD stuff, design patterns, and agile really are big deals. I had no idea.”
• Proving your company really is about the people in it by investing in them. There’s lots of talk at most companies about how much they value their employees, but when it comes down to it training requests are denied on a regular basis. And since so many companies pay lip service to training actually providing it can be a major recruiting advantage.
• One conference can pay dividends throughout the year. Your developers come back with lots of new ideas and continue to research and bring these ideas into their day to day development. Your code base will actually get better and your developers will be more productive. And that extra kick in their step around the office is the sign of a re-energized employee. Energized employees are a great asset.

Unfortunately this is the most common experience:

Nearly a year ago, I posted a question on Spring Forum entitled, “am I working for the wrong companies or is it just not that common to attend conferences?”. I’ve worked as a developer for over six years and as yet I’ve never had the opportunity to attend a single conference. I thought I might be alone in this, but I’ve spoken to a large number of developers who are in exactly the same position, some of whom have worked in the industry far longer than I have.

After some debating I came across the much talked about book, The Little Schemer, at the Borders near Union Square in San Francisco. It compelled me to make a purchase and I’ve slowly started going through the examples. I really like technical books where you don’t actually have to be on a live computer to constantly try the exercises. And the cartoon elephants make me happy.

Next steps:

• Install an xUnit in this case, SchemeUnit
• Install a text editor/IDE looks like DrScheme. (Even OS X screen shots)

I haven’t really spent a lot of time with RSpec since about the 0.5 release. I took a tutorial class with Dave Astels and got jazzed about the opportunity since they were really able to leverage Ruby to make a nice BDD framework. After using RSpec all JUnit test methods started including should. The Rails integration back then was a bit flakey and I just dropped back to Test::Unit.

Version 1.1.2 plays nice with Rails and the momentum of RSpec has definitely picked up over the past two years. Spending time using Story Framework looks compelling as an option for specifying functional/acceptence/customer tests.