Jim, Yes, I agree that this was a reasonable trade as long as this design decision doesn't get carried forward to the new product. (I have to plead ignorance regarding how the new design will implement the storage of user settings.)
Though I am generally pessimistic about fixes that are promised in "next release" of most software products, so far my pessimism has proven unwarranted for most Flex software releases. Mark At 03:03 PM 1/7/2008, Mark Amos wrote: >Alan, > >[begin rant] > >I've had a similar question, but phrased it less delicately: "Is it >just me or is the requirement to build a new database just a bad design >decision that doesn't improve with age?" > >In a previous incarnation as a software developer, I would not have >been able to foist off such a design decision on my boss much less a >consumer products customer (it would never have got past a design >review.) I can hear his first question: "What do you mean you've >designed it so that the customer has to save the database and use a >third-party utility to re-import settings? I can think of 5 different >ways to do this better [he would list them while beating me with a >rolled up copy of the design spec...] Now, go back and re-design this >piece!" > >So, now that I'm no longer a developer but rather an unruly customer, I >get to ask questions like this! In this case, however, it's one of >those things that seems so obvious, I am embarassed to even ASK. > >I can understand it with beta releases -- so I just rebuild it each >time and don't complain (much) because beta users got no right to >complain about nothin'. But really, for production versions of >consumer software. Geez, as da kids would say, WTF? (kidspeak for "That >is a bad idea.") > >[end rant] Production versions of PowerSDR are fairly infrequent (notwithstanding that lots of folks, on this list anyway, do retrieve frequent alpha releases). (Oddly, I couldn't find a list of official releases, but my gut feel is that they're about every six months to a year apart.) I would imagine that the logic behind not fixing it runs something along the lines of: We have 2.0 architecture coming out soon, and that will have a totally different database mechanism, since it won't be using MS Access as the underlying engine. Why deal with migrating 1.x to 1.1+x, now, since we'll have to write some sort of utility to migrate from 1.x database to 2.x database anyway. Not such a bad decision, at that time. Put the resources towards the new version, rather than the legacy. The fact that the transition is pushed out some 3 years(*) or more for a variety of reasons just makes it seem like a terrible decision in retrospect. PowerSDR is by no means unique this way. (*)Yep, it really has been more than 3 years in the making. A couple comments from the mailing list archives (which only goes back to May 2005.. before that it would be the forums): "This will come with the new architecture that is currently being revised for the 1.5 Beta branch of the source." [EMAIL PROTECTED], 30 Aug 2005, 16:35 "..As you may have followed in the discussions this week, we are in the process of restructuring the current code in the interest of enabling people like yourself to contribute more easily. .." [EMAIL PROTECTED], 1 Sep 2005, 14:21 Hey Eric, Has it really been 4 years? Time flies, etc. _______________________________________________ FlexRadio Systems Mailing List FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kb.flex-radio.com/ Homepage: http://www.flex-radio.com/
