One of the things I enjoy the most about being involved in an open source community is learning from the other programmers working on the software. Today was a great example of that, when Paolo suggested an alternative fix to a bug in the MultiClickTool class of OpenJUMP. His fix was much simpler and mind, and avoided throwing an exception to the user. His solution was also obvious, and one I completely missed. This is a very humbling experience, and one that helps you to appreciate why quality in open source software CAN be greater than that of commercial software.
I also find that I am getting better at learning from my own programming mistakes. Let’s consider for a moment, what I learned from my Super Select Tool plug-in for OpenJUMP, which really turned out to be quite a disaster.
The most valuable lesson I took away from my experiences with the Super Select Tool is that simpler is better. I realize now that I just tried to do too much with the tool. I wanted to enable the user create “sticky selections” and also send selected features to a designated layer with a single click. This was really two (2) tools in one. The worst part of this was that one of these tools already existed! It is quite easy to paste selected items into another layer in OpenJUMP, and no separate tool was needed to do that.
My second mistake was to over configure. I realize now that it is often better to create a tool with default behavior then it is to create a tool with behavior that can be configured by the user. This makes the tool design much simpler. Everyone, including the user and the programmer, knows what to expect.
For example: My original incarnation of the Super Select Tool allowed the user to choose if the selected features in the source layer(s) would be removed when sent to the destination layer. Why would I add this ability? The behavior is a little invasive/destructive after all. The user could have easily deleted the selected features by cutting them after selection and before pasting, instead of copying.
Here is another example: I allowed the user to decide if they wanted to copy attributes in addition to feature geometries. Why do that? If I copied the attributes by default the user could still delete them from the layer later.
All of this over-configuration led to more complicated code (can’t you smell all those switch statements) and the need for a configuration dialog.
I know there is a balance between default behavior/configuration. One end of the spectrum is incredibly rigid software, while on the other end is incredibly complex software that is hard to use and maintain. I’m still trying to figure out when it is good to allow configuration, and when you should instead stick to a good default behavior. For the time being, I think I’ll lean towards the default behavior end of the spectrum.
Had I chosen a simpler design for the Super Select Tool, it would have been finished months ago. It would have been easier to install, use, and maintain.
But the effort wasn’t a complete loss. I learned a lot about OpenJUMP’s selection mechanism, about cursor tools, tool boxes, and I wrote some nifty I18N code.
I’ll be reworking the Super Select Tool. This version of the plug-in will be much simpler. It will just enable “sticky selections” and will only have three buttons. No configuration dialogs, no configuration files, and only a single jar to drop in the /lib/ext folder.
Lesson learned.
The Sunburned Surveyor
Posts
