Scheme for This Year’s New Language

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)

RSpec Revisited

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.

Agile With Infrastructure Projects

Agile is really designed around software projects. Infrastructure is a different animal. With an infrastructure project some things start to break down:

  • You usually aren’t writing much code, maybe some database install scripts so no unit tests.
  • Often there’s no continuous integration to speak of.
  • Configuration tasks on new software are often difficult to estimate.
  • Many tasks end up being time-boxed research items.
  • Team members tend to be specialists DBAs or Linux system admins.
  • Most of your team are system admins, but often they aren’t dedicated.

I’ve done a few of these now and generally the most difficult part has been having dedicated staff. System admins and DBAs structure their days around reacting to issues and answering many small requests. The idea of dedicating whole days or weeks to a project is novel. Too novel perhaps as often their management chains are unwilling to dedicate resources.

Our approach has been to use some Agile practices like daily stand-ups and task boards, but these practices haven’t made for smooth infrastructure projects. Since our QA team has been investing in automated functional tests we now have regression suites for some of our major projects, but that’s about the only automation we’ve been able to make use of. It often comes down to a PM/Scrum Master who’s willing to constantly remove impediments by walking around making sure the project keeps moving forward.

Continuous Integration and Enterprise Architecture Governance

Continuous Integration can be a great place to do governance. With good reason developers get the shakes when someone mentions we need more governance. Past history has taught them governance often means someone above them says no.

Continuous integration allows you to inject good development practices and ensure some governance without having to always be the bad cop. Let the build box be the bad cop.

If you’re a Java or .NET shop you can add all sorts of checkpoints to the build and tell at a glance where projects are at and dig into the details. The sorts of things you can do include:

  • Requiring every active project have a build script and be setup on the build box.
  • The code must checkout completely and compile successfully.
  • There must be tests and all tests must pass.
  • Unit test coverage must meet a target number or the build fails. (We use 70% currently)
  • Coding conventions must be followed or the build fails if you have more than say 20 violations. We use Checkstyle to enforce this.
  • The code passes the CRAP metric.
  • The code passes other static analysis checks like Findbugs or PMD.
  • Package dependency analysis using thing like JDepend.
  • Security static analyzers to prove code meets security standards. (I haven’t tried any of these yet.)

All of these steps help you promote good practices, ensure transparency, and give you governance over day to day coding instead of just a review or two at the beginning and end of a project.

Annual Goals with the Dead Man’s Rule

Ran across a wonderful rule when putting together your annual goals.

“A goal that a dead man can meeting is pretty useless.”

– (Comment on Manager Tools)

Some potential dead man’s goals:

  • Improve automation on projects.

All I need to meet this goal is a single developer with an ounce of effort to create a single ant file or shell script. I don’t have to be alive to meet this goal.

  • Engage more with business customers.

If one of my developers talks to a salesperson in the hallway, check, done.

  • Deliver 5 projects.

No one said they had to be big projects, maybe a small production bug fix counts as a project. Again a team could probably do this without any manager.

  • Perform maintenance on System X.

Everyone has maintenance, check.

The guys at Manager tools have a really simple model. The goal just has to be measurable and time based. Thus the goals become:

  • Automate all projects with maven by November 15.
  • Meet a rating of good or better with an annual survey of customer satisfaction for internal customers by September 1st.
  • Deliver Project X with less than 10 severe bugs by May 25th.
  • Reduce maintenance costs on System X by 50% by December 30th.