On 21 Jul 2005 at 23:46, Craig Parmerlee wrote: > On 8 Jul 2005 at 9:18, Johannes Gebauer wrote: > > >I think they are going to have to abandon the yearly upgrades. I > >think it's a really bad business practice in the first place, because > >it places a schedule on development that is artificial -- a software > >development schedule should be determined by the goals of the > >projects currently on the table for implementation/revision/fixing.
No, Johannes did *not* write those words -- I did! Why is it so hard for people to properly maintain attributions? What kind of email client are you using that doesn't automatically take care of it for you? [] > Most code being written today is discarded inside of 3 years, . . . I see absolutely no basis for believing such a statement. Indeed, it's illogical on its face. You mean that code written 3 years ago is now being discarded and replaced with new code. You seem to be suggesting that sometime in the past code was never discarded, or only discarded after some period >3 years, and that recently this has changed. I don't know of any such change. What I do see is a plethora of RAD tools that have entered the market over the last 10 years, as well as a move towards lots of application programming being done for web sites, which seem to be substantially more prone to revision than traditional desktop apps. But I don't know that the code for those websites is being discarded so much as that it's being constantly revised. That would pretty much be the same as every other software development project I've known anything about during the last 10 years or so of my professional life. > . . . so I'd > definitely not want to see any software vendor do anything less than one > major set of enhancements a year. In my business we are delivering a > major release every 60 days or so. I don't know what your business is, nor how you define "major" but it's clearly a very different kind of business than the one MakeMusic is in. > The issue with Finale is not the annual cycle. The issue is the > quantity of enhancements delivered in that annual package. The sad > reality is that these annual enhancements include just a trickle of > enhancements that are genuinely useful to the serious composer, > arranger, or copyist. It seems to a be a company working at a 1985 pace > when most of the software world is working at 2005 speed. . . . I think that last sentence is a steaming pile of BS -- it shows extraordinarily bad attitudes about the goal of software development. It's purpose is not to adapt to some artificial schedule, but to produce the product you want successfully. I know of no application at the level of complexity of Finale that deliverse an upgrade more often than once a year. [] > As users who have a vested interest in Finale surviving, we cannot solve > the software problems for them. But we can buy upgrades to help them > fund the continued development. Anybody who cares enough to post > messages on an Internet board really shouldn't be complaining about > paying a hundred bucks a year to keep the thing going. Ridiculous! Buying the yearly upgrades trains MakeMusic to think they are meeting the needs of their users, that their yearly upgrade strategy is a good thing. If the upgrade is not worth the money DON'T BUY IT. MakeMusic will get the message. Buying it anyway means you've sacrificed any ability to send them a message about your dissatisfaction with the meager enhancements to the current upgrade. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
