One thing most developers hate is dealing with users' error reports. It's not that the users are evil, it just happens that no one has a good solution for communicating what are the results of an error or the conditions that lead up to one.
This is a subclass of the larger problem of communicating software concepts. It's not too dissimilar to the problem of conveying a feature request, walking through a use case, or an experiment proposal. But for now, I'll just stay with the question of error reports.
It seems to me that what might be lacking is the visual component to an explanation. Whenever I have to solve someone else's software problem, I need to see what went wrong. But, this is not convenient when the user is not in the same room. As I'm getting ready to send some simulations that require some setup to a lab on the other side of the Atlantic, I've come to realise that I need a solution to this. I think there may be two practical solutions that could work well on top of the usual collection of core and log files.
Use a remote assistance application. This is fine if you have a lot of bandwidth and are in similar time zones, and you actually know how to use one of these applications. Time coordination and expertise are required.
Use a screen capture program and create a movie of the problem. This has the advantage of being simple to do and it provides a record of the incident for future reference. Given that there are few fairly easy to use screen capture applications (such as Camtasia), this makes for a strategy that should be easy enough for a client or colleague to implement.
Personally, I think video is an underused communication tool. Video is getting easier to handle, be it as real time conferencing, capturing incidents or presentations. It is a communication and collaboration technique that merits further exploration.
Tuesday, November 21, 2006
Friday, November 17, 2006
The Disaster of Unplanned Collaboration
I just witnessed an organisational disaster. One of the other research groups ordered a very large, very heavy table. The table is 2 x 1.5 m and 400 kg; apparently it's part of a very expensive microscope.
In a disappointingly predictable fashion, there was no plan to bring this table into the building. The delivery truck nor the building staff had had furnished moving equipment. There is no ground floor entrance to the building; there was no plan to bring it up the stairs, no appropriate moving equipment and no one supervising to prevent damage to the new equipment or injury to those moving it. The person responsible for the order simply rounded up the available men and asked them to carry it in.
This is the most astounding bit of stupidity and organisational incompetence that I've seen in a long, long time. I found out after that the reason there was no plan was because the person who bought the table did not want to pay the extra 400€ to have it installed. Granted, that's an expensive installation, but given that this is part of a very expensive piece of lab equipment (worth many thousands of Euros), it seems to me that the installation cost would be well worth its value as insurance. Had the table been broken or someone injured, the cost would far outstrip the 400€. In fact, wasting forty minutes of the fifteen people gathered up from around the building probably cost more than 400€.
Thankfully, nothing went horribly wrong and the table did get into the building, though this is purely by luck.
All that was needed was a little planning. We needed the proper moving equipment and direction. Considering that this a site with many labs, with many large, heavy pieces of equipment, there would be some readily available resources for moving and installing equipment. But, apparently there isn't, or, the person responsible for purchasing the table was simply to much of an imbecile to ask for such resources in the first place.
In a disappointingly predictable fashion, there was no plan to bring this table into the building. The delivery truck nor the building staff had had furnished moving equipment. There is no ground floor entrance to the building; there was no plan to bring it up the stairs, no appropriate moving equipment and no one supervising to prevent damage to the new equipment or injury to those moving it. The person responsible for the order simply rounded up the available men and asked them to carry it in.
This is the most astounding bit of stupidity and organisational incompetence that I've seen in a long, long time. I found out after that the reason there was no plan was because the person who bought the table did not want to pay the extra 400€ to have it installed. Granted, that's an expensive installation, but given that this is part of a very expensive piece of lab equipment (worth many thousands of Euros), it seems to me that the installation cost would be well worth its value as insurance. Had the table been broken or someone injured, the cost would far outstrip the 400€. In fact, wasting forty minutes of the fifteen people gathered up from around the building probably cost more than 400€.
Thankfully, nothing went horribly wrong and the table did get into the building, though this is purely by luck.
All that was needed was a little planning. We needed the proper moving equipment and direction. Considering that this a site with many labs, with many large, heavy pieces of equipment, there would be some readily available resources for moving and installing equipment. But, apparently there isn't, or, the person responsible for purchasing the table was simply to much of an imbecile to ask for such resources in the first place.
Wednesday, November 15, 2006
We Need More Tools to Play Nicely Together
I just finished installing Google Desktop 4.5. This is my second try with Google Desktop, I tried it last spring and was disappointed with the performance. However, the performance issues seem to be solved with the latest version.
One thing that it does very nicely is to index my conversations (emails and chats) from GMail and GTalk. This is brilliant. One of the corner stones of good collaboration is good communication, and this helps me work with my previous communications. But, why doesn't Google Desktop work with my on-line files? I have my bibliography at CiteULike, documents and spreadsheets over at Google Docs, bookmarks at del.icio.us, photos at Flickr, movies at YouTube. Shouldn't I be able to index these too?
I think there is an incredible integration of tools that could be done through Google Desktop. I should be able to search for a keyword in my research, something like "biomechanics" or "L-systems", and get back my relevant research notes (from Google Docs), bibliography (from CiteULike), and correspondences (from GMail), all of which exist on line, along side my simulation results on my hard drive.
Additionally, a social layer could be added. If I could index my items online, I could also index my friends' and colleagues' publicly available items too.
And if anyone out there knows of tools to start this integration, please, let me know!
One thing that it does very nicely is to index my conversations (emails and chats) from GMail and GTalk. This is brilliant. One of the corner stones of good collaboration is good communication, and this helps me work with my previous communications. But, why doesn't Google Desktop work with my on-line files? I have my bibliography at CiteULike, documents and spreadsheets over at Google Docs, bookmarks at del.icio.us, photos at Flickr, movies at YouTube. Shouldn't I be able to index these too?
I think there is an incredible integration of tools that could be done through Google Desktop. I should be able to search for a keyword in my research, something like "biomechanics" or "L-systems", and get back my relevant research notes (from Google Docs), bibliography (from CiteULike), and correspondences (from GMail), all of which exist on line, along side my simulation results on my hard drive.
Additionally, a social layer could be added. If I could index my items online, I could also index my friends' and colleagues' publicly available items too.
And if anyone out there knows of tools to start this integration, please, let me know!
Monday, November 13, 2006
The Importance of Code Formatting
I'm currently working through the mess of code. It's not fun. The code is poorly written. It has no consistency in the spacing, variable names, comment style, or name conventions. There's whole pages of dead code and comments attached to nothing.
How did the code end up this way? As far as I can tell, I am the fifth or sixth person to work on this code base. Naturally, there's a small amount of dissimilarity in styles to be expected. That's a speedbump in productivity, but no big deal. But, the person before me to work on the code clearly had no idea what he was doing. The formatting of this code is all over the place. And now, the consequence is that the code is difficult to read and understand. I've discovered several bugs that are due to extra and missing brackets. From bad names and extreaneous comments, the only way to figure out how parts of the program work is to step through line by line and deduce the logic. All of that adds up to a lot of wasted time on my part.
So, how does one evade this problem? I believe that there are two solutions that are needed.
Firstly, there is a need for better tools to do code formatting. Everytime code is checked in to a repository, in must be beautified. Unfortunately, I have yet to find a tool that does a satisfactory job. But there are a few candidates that may work after a few feature additions.
Secondly, a code and documentation style guide should be used. Had I insisted on the use of a style guide early in the project, a good chunk of this mess could have been avoided. And, a printed version of a guide is handy too. When a programmer stops following it, it can be rolled up and smacked accross his nose.
I need to do more work on both these items before they can be put into practice. Hopefully, I'll come up with something that can make my future collaborative programming a saner experience.
How did the code end up this way? As far as I can tell, I am the fifth or sixth person to work on this code base. Naturally, there's a small amount of dissimilarity in styles to be expected. That's a speedbump in productivity, but no big deal. But, the person before me to work on the code clearly had no idea what he was doing. The formatting of this code is all over the place. And now, the consequence is that the code is difficult to read and understand. I've discovered several bugs that are due to extra and missing brackets. From bad names and extreaneous comments, the only way to figure out how parts of the program work is to step through line by line and deduce the logic. All of that adds up to a lot of wasted time on my part.
So, how does one evade this problem? I believe that there are two solutions that are needed.
Firstly, there is a need for better tools to do code formatting. Everytime code is checked in to a repository, in must be beautified. Unfortunately, I have yet to find a tool that does a satisfactory job. But there are a few candidates that may work after a few feature additions.
Secondly, a code and documentation style guide should be used. Had I insisted on the use of a style guide early in the project, a good chunk of this mess could have been avoided. And, a printed version of a guide is handy too. When a programmer stops following it, it can be rolled up and smacked accross his nose.
I need to do more work on both these items before they can be put into practice. Hopefully, I'll come up with something that can make my future collaborative programming a saner experience.
Subscribe to:
Posts (Atom)
