I’m a tools guy. I love to try out new tools. I get excited by the most boring of build tools like ant, maven, or rake or even code review tools like Jupiter or Crucible. In the book Applied Software Project Management they introduce the concept of building support for change through tools:

Another way to approach this situation is to pitch the changes you want to implement as technical tools, rather than as core software engineering concepts. Most people who have been in the field for a long time are used to routinely applying new technical tools that have never been tested in the organization. This is also a good way to gain concensus among the programming team for your ideas.

— pg 217 Applied Software Project Management

If a tool can help with adoption of a new process I think it can make sense, but it’s a dangerous path. Relying on tools for everything can force you into things like Model Driven Architecture. And sneaking practices in with tools is a might bit disingenuous and less than fully transparent. I prefer to use tools to support practices I’m introducing.

Some tools make the practice possible:

• Cruisecontrol for Continuous Integration.
• JUnit for unit testing.

Some make merely support the practice and make it easier:

• Clover to help with TDD.
• Crucible to help with code reviews. (especially if you’re not pair programming)
• Checkstyle to help with code reviews.

Tools can support multiple practices much as XP practices support one another. Pair programming reduces the need for written documentation, enforces real time code reviews, and leads to collective ownership of the code.

Finally, never be afraid to ditch a tool that really isn’t working. I tried using XPlanner for managing a Scrum project, but it really just took more time than it was worth so I dropped it after a single Sprint. If you’re fighting the tool or caught up in tool complexity you’re better off stepping back and dropping it.

I’m working my way through a for fun side project using Rails 1.1 and I’ve been using ActiveRecord migrations instead of the older style SQL scripts. I like them a lot because it allows me to continue to stay in Ruby. Still each time you want to make a change to a table you need to create a new migration script.

There’s a downside to migrations. Over time, your schema definition will be spread across a number of separate migration files, with many files potentially affecting the definition of each table in your schema. When this happens, it becomes difficult to see exactly what each table contains.

–Agile Development with Rails 2nd Edition (Beta)

After a bit of hunting I settled on my current fix. Keep all the changes one per table in their Create ActiveRecord Migration files. Keep all the data migrations in a separate file. When you alter one of them and need to reset your database run two commands:

rake db:migrate VERSION=0
rake db:migrate

Presto, your database is back to a clean state.

Yesterday my organization invented a new Agile methodology–Agile Lite! You might recognize it as Scrum minus collocation.

• 30 Day Sprints
• Planning Meetings
• Product Backlogs
• Review Meetings
• Sprint Backlog
• Daily Standups
• Scrum Master
• Product Owner

The name is a bit humorous, but as long as we get to run it as an Agile/Scrum project I’m not really very concerned about the actual name we use. The best part these days is the strongest proponents of doing Scrum projects are the customers. They really enjoy the control over the direction of the project it allows them.

Approximately two weeks after coming up with a new layout to swap my office into a team room I now have the following:

The vision was to pull out all the cabinets and mount another large whiteboard on the west wall and bring in a couch. This mainly just turns the focus of the room from an office into a meeting room while leaving the space eating cabinets, but it’s 70% of the vision and they only had to remove one desk panel.

Apparently all of the hype around SOA wasn’t enough for Gartner and others so now we have SOA 2.0. Apparently you take SOA 1.0 + Event Driven Architecture. Pure Madness.