As a review of the Enhancement Logs listed in
will substantiate, many of DXLab's most effective capabilities are the result of enhancement requests posted here and then refined
though subsequent discussion. I very much want this process to continue, even though my responses to individual enhancement requests
will sometimes be negative.
I prioritize my "DXLab Development Time" thusly:
1. answering questions posted here by users
2. correcting defects reported here or elsewhere
3. immediately responding to enhancement requests that will benefit a significant fraction of the user community and can be quickly
4. implementing larger enhancement requests that were appended to one of the enhancement logs when first suggested (e.g. unlimited
overrides, or the ability to replace PSK tracking for DXCC with a digital mode specified by the user).
The need for ruthless prioritization is driven by the notion of "opportunity cost": the time I spend working on development task A
is time I can't spend working on development tasks B, C, and D. If A delivers less value to fewer DXLab users than B, C, or D, then
the "opportunity cost" of A is the delay in generated users-value from B, C, or D; if DXLab were a commercial product, we'd instead
denominate "opportunity cost" in delayed revenue or delayed market share.
My initial prioritization is not always correct. In some cases, I have considered an enhancement request to be idiosyncratic,
generating value for only a small number of users - only to be surprised by a cascade of "that would really help me" messages. Or
subsequent discussion reveals that a generalization of the original proposal would make it useful to many more DXLab ops. For me,
this is the most rewarding part of the DXLab experience: collaborating with the user community to develop applications that are
better than what I could develop by myself. If this process sometimes feels contentious, that's a normal aspect of any engineering
process governed by fixed resources; I'm thrilled with this group's long-demonstrated ability to disagree without becoming
Proposed changes to a DXLab application's user interface can be particularly contentious, in that what one user considers an
enhancement may be considered a serious regression by other users. Consider the recent proposal to increase the physical size of
DXView's "Antenna Heading" indicator. My first attempt at this resulted in a slight increase in the height of DXView's Info (Main)
window, consuming more screen space; the resulting expressions of displeasure posted here made it clear that this was unacceptable.
Accomplishing the size increase without increasing the Info window's height required implementing 8 variations of the window's
layout, depending upon whether rotator control was enabled, whether the Special Callsign database was being queried, and whether
the GeogMag panel was displayed. While this was conceptually trivial, working out all the details, coding them correctly, and then
testing every case consumed a lot of my DXLab time -- and Salvatore I4FYV still found a case that I mangled. In general, requests to
"promote" the accessibility of one item at the expense of other items can only be accomplished by giving each user the ability to
position all of the items to his or her liking; while not rocket science either, implementing and testing a general mechanism like
this would take a lot of time, and thus must compete with other large enhancement requests as described above.