Chris Johnston

This is seriously cool technology, and it’s coming from Microsoft. They also announced Surface today, which is their implementation of Multi-Touch.

The world of HCI and computing in general is about to get very cool.

I have a question: can bug fixing be done using Agile methods? Currently, the project I am on is in the last few months leading up to delivering a final product (hopefully) and we are mostly doing bug fixing, performance and functional testing, and other such stuff that a team does in such circumstances. We have done away with IPM(Iteration Planning Meeting)s and retrospectives and are simply squashing bugs as quickly as we can.

This seems to be working, but I am not certain that it is the best way to proceed. On one hand, it frees us from committing to certain bugs allowing us to switch to more critical bugs as they come in and on the other hand, it makes it harder for us to track what we are doing since too much context switching can result in some bugs languishing in a half solved state for too long. Although this rarely actually happens since developers usually try to finish a bug before switching.

I think one of the biggest problems with this approach is that any pair is expected to pick the next highest bug on the list regardless of whether they are the best people to fix that bug. There is no real idea of self organization or the team decided who is going to work on what. For the most part, we are simply told what to work on.

I think this is what I dislike most about this format. There have been a few bugs that I have worked on that have taken several days to fix whereas a more experienced developer with domain knowledge could have fixed it in a few hours. I am not sure what business value this provides to the client?

Anyone else have any thoughts on this? Can bug squashing be done using Agile techniques or are they only good for the “real” development stage of development and not for delivery or maintenance?

Since xDD terms are all the rage right now, I think I will introduce another one: Interface Driven Design. And by Interface I don’t mean the kind that Java classes implement. I mean the kind that humans use when interacting with a computer.

The idea is very simple, all GUI based software projects–software that real people interact with–need to start with the design of their interface first before any coding begins. And that interface needs to act as the blueprint for everything that is developed. If there is no place for it in the interface then either the interface needs to change or the feature is dropped. In addition, you know that you are finished a feature when that part of the interface works.

The design of the interface serves two purposes:

1. It helps to focus the business requirements gathering process and give form to what the client wants and
2. It guides all development going forward.

The last very important point about interface driven design is that the designers should never go away once coding begins. They are as important to the project as developers, business analysts or quality assurance people are. Their job is far more then simply drawing pretty pictures and making the screen usable, although, the latter point is still a very important part of their job.

Interfaces need constant tending. They are like little children that, when not watched, get out of hand and loose focus. It is the UI designer’s job to keep everything in line and ensure that the interface stays true to the original project vision.

One problem is that many developers do not see the importance of designing good usable interfaces to their software. “It can be added at the end once all the real work is done”, they say. But this is false on several different levels.

First, without an interface, how do you know what the customer wants? they may ask for a registration screen, but without having worked through the exercise of designing that screen and showing it to the client, how do they know what information should be on that screen?

Second, the interface is very lightweight and can be changed easily and quickly. it can also be change many times before a decision is reached. Paper and pencils are very cheap. So by starting with, and returning to, the interface, you keep the project highly Agile. By the end of the design exercise, the client knows what they want and the result is clearer requirements for the developers. Both sides win.

None of this is new to me. Parts are taken from 37Signals, the group that created Basecamp and Backpack and parts are loosely taken–and possibly misrepresented–from a talk that I attended on Behaviour Driven Design. The gist of the talk was to start with the interface. To start with what the client needs and derive your requirements from it. Whether that interface be a computer screen or a laser etching.

This point has been driven home to me over the last several weeks. I am working on a small Ruby on Rails project. I have a general idea of what the app is, but I have neglected to do wireframes or sketches of the interface. As a result, development on the project has slowed. This is because I don’t have a clear idea what is needed and what it will look like to the end user. I am now going back and creating sketches of every single page and creating static HTML to go with each sketch.

This will give the project focus and really guide the development as I work to implement each feature in the HTML mockups. Once the interface works, I can then go back and figure out where new features fit and what they will look like.

Andy Marks has written an excellent blog entry about the power and importance of information radiators to the success of a project. In this case, it is a story card wall that allows both the development team and the client see what stories are being worked on and what stories have been completed. This informs everyone about what is going on and focuses the conversation between the devs and the business people.

The marketing and sales people started asking questions about the purpose of the wall and quickly understood what information it was showing. They were most appreciative of being able to see what features were in development, completed or not yet started. Based on this increased understanding, conversations between the business and the development team increased and were based on a common understanding of the current state of development.

The project that I am working on does not have any of these information radiators and we have run into problems of communication between the client and the team with the client not knowing what has been accomplished and what we are working on. Our story card wall is not in another room, it is in another state.

The culture of the client would make putting up story card walls in high trafficked areas difficult if not impossible, but I have to wonder if we could do it how much it would help to decrease our communication problems.

The project that I am on right now is in the “go-live” stage. This means that we are basically fixing the last remaining bugs in an already implemented system and getting it ready to go into production. The consequence of this is that there seems to be very little time to learn the domain or the implementation.

In order to fix a bug you already need to understand the domain and no pair stays put in the same part of the implementation long enough for a new developer to learn the code. In addition, the client is looking for bugs to be fixed as quickly as possible which results in the experienced developers doing all the work and the new one simply looking over their shoulders and trying to keep up.

I am looking for tips on how to catch up — what is the best way for a new developer to such a project to learn the domain, the implemented code, and the technologies that that code is built upon as quickly as possible.