Random Thoughts on Software

In my experience, when it is suggested that a conversation be moved from a mailing list to a Wiki, nine times out of ten the conversation ends immediately without making it to the Wiki. When a conversation is transferred to a Wiki, nine times out of ten the conversation dies within a day.

Please don’t disrespect your co-workers and end a good discussion by asking that it be moved to a Wiki.

A Wiki is no place for a conversation. Just take a look at the conversations on the C2 wiki and see what an utter mess they are. Nobody can follow the conversations, yet we all know they contain valuable information. The most important technical criteria for encouraging participation in online conversations are distribution, presentation, chronology. In my opinion, conversations should be distributed in a push fashion, presented as discrete responses (ideally as a threaded conversation), and should appear chronologically so that people can see the history of the conversation. If these things don’t hold true, people don’t contribute to the conversation. These criteria are much more difficult to achieve in a Wiki than through a mailing list.

In addition to the criteria that promote participation, making your conversations searchable and archivable is usually a good idea. If you are asking for a conversation to be moved to a Wiki because you feel like its important and you want it to be captured, then you might consider using forum software (or an online newsgroup) instead of plain e-mail distribution.

A lot of teams have trouble deciding whether a task should be declared as a technical task or a story. The simple answer here is that if a customer can ask for it, it should be a story.

For example, the following should be stories:
- Creating an installer - “As a customer, I want an easier way to install the application”
- Supporting an incremental DB tool (such as Liquibase) - “As a customer, I want an easier way to the application database when upgrading software releases”
- Supporting a new deployment environment - “As a customer, I want to be able to run on a 64-bit HP box”
- Improving the system performance - “As a customer, I want to run WizBang transactions faster (i.e. denormalize WizBangFoo and WizBangBar database tables)”

The following should be technical tasks:
- Refactor the new domain objects to eliminate duplication
- Make sure that PMD and Clover are running with the nightly build
- Run a continuous integration build
- Test integration between FooServer and BarWebService

Just because something sounds technical (like improving performance or supporting a new DB tool) doesn’t mean that it can’t be captured as a story. The problem with not capturing customer requirements as stories is that it becomes unclear when they should be prioritized. Who gets to decide? The team lead? The product manager? The architecture team? The project manager? The team? The receptionist?

The other problem is that you don’t get credit for the work and effectively devalue the stories that you are working on in the iteration in which you take on the (miscategorized) technical task.

Take a closer look at the tasks that you have sitting on a punch list or task board somewhere and see if it could be asked for by a customer. If so, write it up as a story and hand it over to your product manager.