Monday, September 05, 2005

OnTime Setup Notes

This post is just some notes taken while setting up OnTime and importing data from existing spreadsheet files. It falls far short of a review as time is precious! These quick notes are hopefully useful to others that may be looking at the package in a similar setup scenario:

  • The install was fairly easy as I already had an existing MSDE database setup. At this stage only the Windows Forms version of the product was installed.
  • The SDK wouldn’t install without IIS installed. The initial plan was to write an import program using their SDK but I found there was a CSV import menu item and decided to use that instead. The CSV import allowed me to easily select which spreadsheet columns mapped to which OnTime fields.
  • The original spreadsheets used for feature/fault tracking had three spreadsheets in the workbook: features, faults and tasks. These mapped nicely to the OnTime concepts of defects, features and tasks
  • I had a few goes at importing the feature spreadsheet data to get used to the process and tailor it as needed. A large number of feature entries had to be deleted in this “experience” loop. It seemed quite slow in deleting entries - around 2 a second.
  • It was also quite slow when I had to drag 200+ features from one project in the hierarchy to another. The UI didn’t help in telling me what was going going on. I wasn’t sure it hadn’t crashed during the process so I just left it. It did eventually move all the features to the new project location.
  • Added Very Low, Very High priorities to the priority list. This is a sweet feature in that you can easily tailor the priority levels to your own needs. It also allowed the order of the priorities to be configured so that sorting in a grid doesn’t rely on the alphabetic sort order. In other words when sorting on Priority, I get entries in the following correct order: Very Low, Low, Medium, High and Very High. It doesn’t seem to use this ordering when grouping on a column though.
  • Added custom fields for Vendor and VendorReference. This is where a product defect is actually due to a third party vendor’s defect. It was easy to specify all the Vendors I deal with as items in the pick list for the Vendor field.
  • The spreadsheet columns didn’t include the concept of a feature/defect state only a percentage completion value. This was easily handled by adding a calculated column in the spreadsheet that used an IF() Excel function to define different states depending on the percent complete.
  • I had used Excel comments to put additional information into the features/faults spreadsheet. An Excel comment appears as a small filled triangle in the corner of the cell. Hovering over this triangle causes a small comment window to hover above the spreadsheet. This was a weak way of adding additional info to the entry. A user defined VBS function was used to get the comment data into a spreadsheet column and hence into the OnTime database. See for the script used.
  • The import dialog didn’t go back to the last import directory. As I was testing a few approaches and had to repeat the process for a number of workbook/worksheet combinations, this became increasingly annoying.
  • Grid scrolling somewhat jerky in the OnTime windows forms UI. There seemed to be a lot of needless repainting going on.
  • Some times the user interface would pause for a short term before giving you back control. This was usually during accessing another functionality area of the package. It wasn’t a big deal but it was still noticeable.
  • Expected a select-all or Ctrl-A in the grid control and there wasn’t one.
  • Selecting large numbers of rows takes a while (around 2 seconds for 200 rows)
  • Page up/down don’t do anything in the report viewer when I expected it to. You have to use the paging buttons.
  • After importing defects and features from the spreadsheets, I went to import the tasks worksheet. Unfortunately there is no import tasks functionality.
  • From an import perspective, I couldn’t find a way of defining the date at which the feature/defect came into being. This makes some of the reports after an initial import not much use as they rely on the date the entry was placed into the OnTime database.
  • Added some new feature/defect entries manually that had been lingering in my inbox. It was very handy to be able to include relevant attachments to an entry and being able to just double click on them to view. That was something that wasn’t easily done with a spreadsheet based system.

Now the new defect and management system with all the existing data has been put in place and it will be used over the coming months.


In essence this is just a link to Axosoft to take advantage of a promotion to get a second free license of their Bug Tracking Software. Around three years ago we started on developing a specialized financial application. At the time we actually considered purchasing the OnTime product but instead decided to go with the “agile” approach and just use a basic spreadsheet i.e. no more than what was needed given there was only a single developer and a support engineer involved.

The spreadsheet worked fine and has been used for a number of development projects, but seeing the review by Scott Hansellman triggered the thought processes. I’m in the process of reviewing the company workflows and having a hierarchical breakdown of defects, features and tasks with some canned reports would certainly be a step up from a spreadsheet. It would save some workflow time, but more importantly I need a way of easily getting a sense of “the state of the nation” with respect to any single development project or sub-set of it. The free license approach is useful in that I can give the product a go and if it works well, purchase additional licenses as the company expands. If it doesn’t work well then it’s no big deal.

I did consider using the defect tracking features of Visual Studio 2005 Team System and will investigate that in more depth later this year after the Whidbey release. The impression given by various blogs and the MSDN website is that it’s a more heavy weight approach to set up and then there’s the whole pricing thing. A big chunk of change is needed to get access to Team Edition functionality for each developer. Its unclear at this stage whether its better to go the whole hog with Team Edition or use the lower end VS.Net versions and augment it with third party products such as OnTime. The plan is to use the OnTime SDK to read the defect/feature/task data and export it to another format if there is a need to change the bug tracking software in the future.