From Journeyman to Master

Fit stands for FrameworkForIntegratedTest. The following is from Wikipedia:

Framework for Integrated Test, or “Fit,” is an open-source tool for automated customer tests. It allows customers to provide examples of how their software should work.

Notice the word customer appears twice there?

We actually have a pretty good Fit Test framework. It uses a combination of Excel, JUnit and Watir. Excel is used for data input, scripting tests and assertion. It makes our Fit tests easier for non-geeks customers to use. Although, our onsite customers were not very keen on this idea. Writing, maintaining and verifying tests has always been only the developer and QA’s responsibility.

With the newest progress in our project, the focus has been switched from finishing stories to completing scenarios. One of the things we are trying out is to really get customers involved in Fit Tests because it’s the only way we can ensure the scenarios are completed and stabilized. Two of our brilliant developers, Mike and Celina, enhanced our Fit framework to make it even easier to use. So let’s hope we will be real Fit this time.

There are a couple of things I would like to try if I’m going to start a new project.

• Use a good code formatter. I’m a two spaces indentation guy. I think four spaces indentation is a total waste of screen real estate. No, no tab. Everybody should know that by now.
• Start using test fixtures from the beginning. It’s surprising how my last two projects end up the same path – first helpers and then refactor them to fixtures.
• Choose a template based GUI framework such as Wicket or GWT instead of Struts. Damn I hate XML files. I didn’t think it’s a good idea when it first came out. But everyone loved it. Now apparently everybody is staying away from it. People! Listen to what Simon says!
• Avoid bloated DTO if I ever have to use it.
• Write unit tests instead of functional tests. Make more use of stubs and mock objects.
• Keep the members and methods sorted. It makes it easier to browse the source code and for version control systems to merge.

10 Things Java Should Steal from Ruby should be a nice read. I might have a separate entry about it. This entry, though, is about something I came across in the article – a Smalltalk refactoring browser. Yes, refactoring does not have to require static typing! Does it mean we can do it with Ruby, too? The answer turned out to be yes. Check out Ruby Refactoring Browser. It’s still in a really rough stage. It looks like that it can only be used with Emacs. But it’s promising. I hope more people will pay attention to this project. It will definitely attract more developers to Ruby and bring Ruby closer to enterprise world.

Recently, with about half of the team on vacation, it’s been hard to pair. That caused some crappy code to be produced. I personally contributed some of them. So today we had a team meeting on what we can do to improve the situation. The result was very good. We came up with a couple of things we would like to try.

• First of all, we like pair programming.
• Code review cannot replace pair programming.
  • People cannot remember every piece of code they wrote.
  • Code review has much less coverage than pair programming.
  • It creates the wrong perception that it’s something personal because you are pretty much saying other people’s code sucks.
  • It’s missing one of the (more important) benefits that pair programming offers – generating alternative ideas.
• Make pair planning/switching a mandatory part of the daily standup. Distribute the responsibility to the whole team instead of just the team lead.
• Use a combination of fix interval (one or two days) and functional point (after finishing a task) to decide when to switch.
• Will consider having a story owner on hard stories.
• A pair should not stay together for longer than three days.

That’s all I can remember for now. I think it will definitely help improving the pairing in our team.

During the meeting, one of our junior developers said that he/she would like to have some alone time fixing bugs so he/she can learn more about the system without interference. In my personal opinion it is very dangerous. In our project (actually pretty much every single project out there), a bug is not necessarily smaller than a story. New team members who tackle a bug alone might think they made a trivial change. But that change could affect quite a few other functionalities down the road. Since new team members usually need some time to get familiar with the test suite, they could end up checking in broken tests.