Darren Steadman

Earlier in the year I posted about helpful software errors, this article builds on this and offers a discussion into making it as easy as possible for users to submit relevant issues with software but at the same time making the information as useful as possible to the developer.

Let’s outline some of the things that could be done.

Gather anonymous statistics

There are already lots of applications out there that gather anonymous statistics about their usage. This can be very useful for finding out simple information like how often a feature is used and how people get to that feature (so many apps still have 100 ways of doing the same thing). This can be useful when devising test plans or when deciding if features should be dropped or if features should have more time spent on them.

In application issue submission

The first time I saw this happen was in one of the Windows 7 betas, they added feedback menus to all windows so that users could submit bug reports or feature requests from a relevant place. I think it would be useful for applications to have a feedback button on all of its major features so users can quickly file bugs and feature requests that can automatically be categorised based on UI elements. Combine this with the anonymous data gathering and it gives you an idea of priorities when fixing bugs or implementing new features. It could even be possible for users to view other users submitted issues for a feature allowing them to up vote the problem or even provide additional feedback to the issue. It would also be possible to give feedback to the user on the status of their issue via the application itself. This kind of system brings the support system right into the application itself rather than forcing people to find the application support somewhere else, it also gives a sense of good customer support to the user as they feel they have visibility as to if their issue is being addressed.

Application container

I know this kind of thing can in theory be done in .NET and I assume depending on security restrictions it could probably be done in other VM based languages. You could run your application in a container that recorded the state of the application, so basically stack traces and memory contents. This data could then be played back later while the application was attached to a debugger to see what the user did to create the issue and what state their application was in. Microsoft already provide such a container but licensing means it can’t be used in a shipping product. A less full blown equivalent could be a way of recording what buttons were pressed and when as well as values entered via the keyboard this would then allow you to recreate the application state rather than record it directly. There are obvious security and privacy concerns related to this kind of recording but it could be possible to implement it in such a way that the user could explicitly turn the feature on to help diagnose a problem.

Well that’s a short list of potential starting points to allow better more accurate issue capture in applications.

A friend recently posted about using a chess timer in software development. This is my argument against the conceptual need for it.

The main reason stated for the timer is to indicate when development has had to stop on a project due to needing external events to occur, those events could range from a decision being required to something being signed off to requiring a piece of information.

It is stated by the writer to his own admission that he is bad at estimating development timescales and I believe this is the problem here and why the timer is required.

If you can’t estimate your own timescales then how do you organise your workflow and the workflow of people around you? Time wasted on waiting for decisions can be massively reduced by knowing your timescales because if you know your timescales you understand the extent of the work you are doing and the key bottleneck points, if you understand them then you can make people aware of decisions that need to be made in advance to when you need them reducing any time waiting for things you require to continue.

This obviously won’t eradicate all wasted time, there will always be situations in the development cycle where unforeseen problems will occur but even these can be massively reduced with correct specification of the work to be done and by keeping a tight iterative process where problems from the previous iteration can be addressed while another iteration is being implemented.

In conclusion I think the timer isn’t required if time is spent at the specification phase to identify as many as the problem areas as possible. Development should then be done in tight focused iterations and most importantly good time estimates are given so that all people in the development are aware of when information is required.