In Ruby, I hate require statements that look like this:

require File.dirname(__FILE__)+"myComponent/component.rb"

So I decided to do something about it.

A few weeks back I was working with a team on the East Coast. They wanted to develop a simulator to assist in testing other software components. Their system to simulate is well-described in a specification using diagrams close to sequence diagrams as described in the UML.

In fact, these diagrams were of a variety I’d call “system” sequence diagrams. They described the interaction between outside entities (actors – in this case another system) and the system to be simulated.

This brought be back to 1993 when I was introduced to The Fusion Method by Coleman et al. Before that I had read Booch (1 and 2) and Rumbaugh (OMT) and I honestly didn’t follow much of their material – I had book knowledge but I really didn’t practice it. I always thought that Booch was especially strong in Design ideas and notation but weak in Analysis. I though the opposite for Rumbaugh, so the two together + Jacobson with Use Cases and Business Modeling really formed a great team in terms of covering the kinds of things you need to cover in a thorough software process (UP + UML).

But before all that was Fusion.

I am mentoring a team that is transitioning to XP, the first team in a planned, corporate-wide transition. Recently we ran into miscommunication problems about an interface we are providing to another team.

The problems didn’t surface until a “big-bang” integration right before a major release, when it was too late to fix the problem. The feature was backed out of the release, as a result.

There are several lessons to take away from this experience and a few techniques for preventing these problems in the first place.

My son Justin is working as a Ruby apprentice for my son Micah at 8th light. We were sitting at the kitchen table, and he showed me a function he was writing. In the midst of the function I saw this:

handle_batch(item) and display_batch(item) while items_remaining?

I looked hard at this and then I said: “Justin, I don’t think you understand what and does.

This has been done before by another mentor, and it was fun. I’ve been watching my use of refactoring tools, and here is my top five list of seven most-used refactorings:

1. Rename
2. Introduce Variable
3. Extract Method
4. Inline variable
5. Inline method
6. Move Method
7. Change method signature

You might guess that I’m doing a fair amount of refactoring on legacy code.

I was suprised how much I’m using introduce/inline variable, but quite often I’m doing that to make a block of code ready for method extraction. Having broken out small methods, I sometimes find a larger method to extract, and then I inline the use of smaller methods. It’s sometimes hard to find the right level of generality.

I’d have trouble imagining that the first three weren’t everyone’s favorite refactorings.

We know that maintenance is 90% of the software lifecycle, and 90% of the cost. We know that our systems need to be flexible, reusable, and maintainable. Indeed, that’s why we spend so much of our time trying to get the design and architecture just right. Because we all know that good design and architecture is the key to flexibility, reusability, and maintainability…right?

Test driving user interface development has always been a challenge. Recently, I’ve worked with two projects where most of the work has been on the user-interface components.

I’ve seen it as I’m sure you have. You look in to a conference room, there’s a spreadhseet or a word document or some such “deliverable” displayed on the overhead. There’s one person engaged, talking about it and N – 1 people with glassy-eyed stairs, hoping for the meeting to end.

What’s even worse. You have the next meeting in that same room and you know your meeting is going to be a repeat of the previous meeting. Even so, it irritates you when they go over because that meeting room is yours.

Make an agenda! That’ll solve it.

Maybe, but probably not. Most agendas are task-orietned rather than goal-oritned. So you might make it through the agenda but what have you accomplished besides following an agenda?

When people discuss wasted time, do they joke about meetings? Do they? Are you listening? If people are joking about meetings being a complete waste of time, then the meetings are probably a complete waste of time. (Ever consider keeping a count of the number of times you hear the same thing during a single day? You’d be amazed what you can learn by just listenting to your team.)

I have a theory.

It’s one of those theories that I don’t want to get ruined with actual facts, but I suppose I’ll put it out there and see what I learn.

The theory stems from a series of observations about the way some Microsoft development shops write code versus others. I’ve noticed that some shops like to make many things sealed (final). I’m not talking about the occasional class, but rather the default is to use sealed on most things. In addition to classes being sealed, there’s a heavy bias against virtual methods. I’ve not noticed this with Java development groups, though in the spirit of honest disclosure, I’ve only noticed thins tendency is about 50% of the MS shops I’ve visited – and it seems like the tendency is reducing.

I came across a quote in something I was reading, and I can’t recall if it was a blog, a cartoon, a book, or what. A young woman was talking to a politician and asked if he had to make a lot of compromises. When he admitted that he had to compromise a few times, she shut him down by saying “you can only compromise your values once, and after that you don’t have any.”

I had a talk the other day with a fellow mentor, and brought up line only to have it returned to me (with top spin!) when we were talking about when would be the right time to turn on an older suite of tests in CI.

I finally had a chance to examine the decision point. Of course, it’s always the right time to turn on more tests. When do you not want to know if your code stinks? On the other hand, I knew:

1. these forgotten tests were not used by developers, and so are of dubious quality
2. the team in the middle of a big stabilization crunch
3. the team is in their final coding week before release.

While they need to know their code and test quality soonest (preferably before release) there was emotional foot-dragging on my part. I knew that they didn’t have the headroom to even triage the old tests to see if they should pass.

The problem was not of compromising my principles so much as choosing which of my principles would have sway. On one hand, the quality driver knows that we need more tests sooner. On the other hand, I knew how close the team was to being overwhelmed to the point of shutting down. My nurturing, coaching “spider-sense” kicked in when I wanted to turn on the tests, and my XP quality-driving “spider-sense” kicked in when I thought about not turning them on.

I decided to wait only a week, and then get the tests turned on. Was it the right decision? I can’t tell. I am truly ambivalent; both drawn and repulsed by the decision. Sometimes the good is the enemy of the best and it’s hard to see which is which.

I chose to be the kind of guy who would err on the side of compassion. It’s the more personal and superior of the two values. Having decided, I move on.

But now it’s time to get those tests running, and sooner is better.