I am a programmer, too, and for about as long. I have encountered situations similar to what you've described below. There may be issues with having large staff lists (performance, field count bit size, whatever), but I can't see the reason for 4, as opposed to say, 8 or 16. I am not in their shoes, and maybe they've encountered a limit beyond my experience, but I find that hard to believe. They've removed features - they did not warn the user base, they did not "deprecate" old features, and I think that is what most find offensive. We have had no time to prepare, and have forced some of us to consider not upgrading (I did upgrade, by the way, and I like WinFin2k9). This is simply bad business. And, in the battle between business needs and programming, I have found that programming usually loses. Seeing as they have not cited any programming benefit, I can only conclude otherwise. Of course, if any of the MM lurkers wish to correct me, I will stand corrected on that point.
Nevertheless: removal of a capability, no user base preparation (I mean all of us), and, in my mind, several workable alternatives to what they could have done, instead. Goodness - they could have written a plug-in that would scan the document and say "hey, too many staff lists - WB will be upset!" if it were just the publ houses. Sorry. As a long-time program project manager, this is a hot button for me. ---- Craig Parmerlee <[EMAIL PROTECTED]> wrote: > I wonder if we should be giving them some benefit of the doubt on this > subject. As a professional software designer for 35 years, it seems > entirely plausible to me that they may have faced a point where > preserving unlimited staff names, in combination with other new > features. would have taken significant extra programming and testing > effort. In cases like that, I believe it is appropriate for the system > architects / business planners to make some judgments about their > overall vision for the product. That seems to be the case in this > instance. Their vision is, evidently, that they want to put their > effort into the more elegant organization of expressions. > > If there were absolutely no trade-off involved and they made this change > just to be hard-headed, that would be a bad deal. I really doubt that > was the scenario though. > > > > [EMAIL PROTECTED] wrote: > > Seems to me that if they wanted to put in limitations for some publishing > > house, it would not be unreasonable to put in a "policies" configuration > > where you can select, say, the WB or B&H guidelines and styles so the > > various houses get what they want. For the rest of us peons who have > > different "guidelines", we can select the same old personal style we've > > been using since, well, forever. > > > > _______________________________________________ > Finale mailing list > Finale@shsu.edu > http://lists.shsu.edu/mailman/listinfo/finale _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
