View RSS Feed

Development Team Blog

Suggestions - How we make mountains out of molehills

Rate this Entry
There was a recent forum thread suggesting that the Studio's codesense should provide assistance with index selection for the Find command. We noted that this suggestion actually was implemented but that it was implemented in a slightly different manner. As expected a lively discussion ensued. This presents a good opportunity to discuss how we implement suggestions. We can use this suggestion as an example.

The suggestion was that codesense should pop up a list of all available indexes with information about their segments. Let's say you type:
Code:
Find GE MyTable by
As soon as you type the space following the "by" a list of indexes and index information should be presented for this table. Great suggestion!

Whenever we get suggestions like this we try to abstract the specific suggestion to see if there are larger issues at play. What is the problem this is trying to solve? Is this just one instance of a larger set of issues? Will this suggestion work for everyone? Are there holes in the logic? Does this fit within our development direction or does it head down the wrong path? Will this lead our developers down a wrong path? By the time we've worked this through we may find that the suggestion was perfect as is, that it needs minor changes, that it needs major changes, or that the whole thing fell apart and is just not doable. This is our job - we make mountains out of molehills. Very often simple suggestions become much more complicated. And just so you don't think we only do this with your suggestions, you should be around when we make our own internal suggestions. The main difference is we are much crueler with ourselves. There is nothing quite like watching your brilliant idea torn apart right before you eyes.

In the case of this codesense suggestion, we interpreted it as a need for a quick and consistent way to see what indexes are available for a table. While this suggestion was limited to the Find command (actually limited to one variant of the find command) it is something that you need all over the place. You need this when typing the Find command. You might need it when moving data to a table.column (after all, you need to know how to seed your tables before finding). You need this when typing DataDictionary find messages where the index may be in any parameter (e.g. Send Find, Send Request_Find). You need this when setting properties (e.g., Set ordering). Most importantly you need this when reviewing your code. As part of the review process, you need to know information about the index you selected and often you need to know information about the indexes you didn't select. I don't know about you, but I spend much more time looking at my code than I do writing it. To add one more complication, often the index number will not be a literal (e.g., 1, 2) but a variable or even a user defined constant.

As you can see, the suggestion only solves this problem for one special case - typing the Find command. Our job is to create a solution that works for all of these cases.

Our solution, which was added to Visual DataFlex 14.1, was to provide two mechanisms for obtaining table, column and index information. You can 1) open up Table Explorer to inspect the table or 2) hover the mouse over any table or column name in your code. Once you understand how this works, it works in a consistent manner for all the needs listed above.

For what it's worth, we even argued whether we should offer two ways to do the same thing. We often find that offering too many ways to accomplish the same task is a symptom of bad design. In this case we felt that these alternatives complimented each other. The code hover over feature often provides the quickest and most context oriented way to find table information. Table Explorer can be used to find information about any table even if it is not in your code. Both techniques serve a purpose.

We also considered adding codesense to the Find command but we felt that it would not be useful enough to justify creating yet another way of obtaining index information. Let's look at an example:
Code:
Clear MyTable
Move sName to MyTable.Name
Move "A" to MyTable.Status
Find Ge MyTable by 17
First of all note that we did not use Index.17. The symbol Index.17 is not defined and you will get a compiler error. An SQL table might actually have an index 17. We only define Index.0 through Index.15 (defined as 0 through 15). Rather than defining new symbols for every possible index number we felt it is easier to just use the number. Therefore we have been discouraging the use of the "Index.xx" syntax and suggesting the simpler use of the number instead. If you just enter a number, you can't justify adding codesense to make typing easier. If you know the index number, you just type the number. We can't make that much faster. If you can't remember the index number (and I never can) you can move your mouse over MyTable, find your index information and continue typing. Actually by this point you might have already used this same hover over technique to remember which columns needed to be seeded before the find. If the code didn't work (and for me it never does the first time) you'd use the same technique during debugging to make sure that you seeded things properly and picked the proper index.

Now let's change this and create a few DataDictionary examples. If you wanted to do the same thing with DD objects, you might have:
Code:
Send Clear of hoMyTableDD
Move sName to MyTable.Name
Move "A" to MyTable.Status
Send Request_Find of hoMyTableDD GE MyTable.File_Number 17
or
Code:
Send Clear of hoMyTableDD
Move sName to MyTable.Name
Move "A" to MyTable.Status
If (bOrderByStatus) Begin
    Move 17 to iIndex
End
Else Begin
    Move 5 to iIndex
End
Send Find of hoMyTableDD GE iIndex
What's nice is that you can use the exact same hover over technique to find your index number.

Just to be difficult, let's add one more example:
Code:
Get Main_File of hoMyTableDD to iMain
Send Clear of hoMyTableDD 
If (iMain=iSomeTableNumber) Begin
    Move 2 to iIndex
End
Else Begin
    Move 1 to iIndex
End
Send Find of hoMyTableDD GE iIndex
Now there is no table name to hover over. At this point you use Table Explorer. This last example is rather unusual but it can happen and we can support it.

We really do pay attention to your suggestions. What may not be clear is how much time we spend discussing and designing these kinds of suggestions. The scenario I've described above is just a summary of the design decision that was reached after hours of meetings where we floated multiple ideas and solutions before arriving at an actual design. By the time something like this is implemented it may not be exactly what you suggested. You give us the molehill and we thank your for that. In return, sometimes we give you back a completely relocated molehill (moles do that you know) and sometimes we give you back a mountain.

Comments

  1. Focus's Avatar
    Well that told us

    Seriously though an interesting read and it certainly makes sense to me why you chose the route you did