On 6 Jul 2007 at 20:27, Christopher Smith wrote: > On Jul 6, 2007, at 8:25 PM, David W. Fenton wrote: > > > Now, I think that it would be good to keep hitting them on the ones > > that he says are scheduled to be fixed, maybe three months from now, > > and ask if they are making progress on that. If multiple people did > > that, it would encourage them to get cracking if they haven't > > already resolved it. > > Yes, I think that would be an excellent strategy. You apparently have > some understanding about how these things work in software companies, > which is more than I can say.
I make my living in part from developing software, so, yes, I understand. I try to respond to my clients' bug reports as quickly as possible, but sometimes I run into big issues. Obviously, any bug that I can fix in 15 minutes, I fix immediately. But the ones that are caused by complex interactions with fundamentally complicated subsystems of the application itself get longer consideration. There's always the issue of unexpected side effects -- you change one thing and it cause an issue somewhere else. This is no doubt the chief reason that these long-standing bugs have not been fixed already, because doing so requires changing something elsewhere that could have major repercussions in other parts of Finale. Generally, the way to fix these kinds of issues caused by major interactions of this nature is to refactor the underlying code. "Refactoring" is the process of rewriting the code so that it is structured completely differently, but behaves exactly the same way. A simple Finale example would be to combine 3 movements into a single score. The user of the printed score won't see a single difference, but the engraver will have done significant work in combining the three fiels (at least, previous to Finale 2008!). The result is that it's much easier to generate parts, for instance. In coding, refactoring is something you do to restucture code in a way that makes it more extensible, more easily re-used. You try to emphasize code re-use, and create code "objects" that have defined interfaces and can basically function as "black box" objects that you don't need to know what happens inside them, only how they interact with the other code. This kind of thing is *very* complicated. And when the code yoi're refactoring already is designed according to those basic principles, the harder it can be to refactor sometimes. But it's the first step towards building a better app. It's kind of like remodelling a house. Before you can add that second floor, you probably better rebuild the foundations and the 1st floor walls. When you've done all the rebuilding, the first floor is no different than it was before, but now it's ready to hold up the second floor. This is one of the things that's hardest about software development -- remodelling that first floor is often far more work than building the entire 2nd floor, and you get no credit for it. If you saw in the README of a Finale release "revised the graphics subsystem in preparation for new features in next release -- no changes of functionality or bug fixes" you wouldn't be too excited. But that's what often has to happen first. And the schedule for a piece of software that releases every year is *very* tight. I would expect that after Jan. 1st or maybe Apr. 1st, there won't be any major changes to what is planned for Finale 2009. I'm not just talking about major new features, but things that from MM's point of view require a major overhaul of existing code. My guess is that the enharmonic bugs introduced with linked parts will be fixed in the next release, as will the other bugs with linked parts. The reason for that is that you skip enhancing a major subsystem in one release just to keep something stable. Really, from what I've heard about linked parts, I think MM did a remarkable job of getting it into Finale in little more than a year after Sibelius introduced the feature. My bet is that it was already in the works long before that, or they wouldn't have been able to manage it so quickly after Sib4. I think a lot of the new features of Finale 2008 look like half- completed major revisions that reflect long-standing feature requests, e.g., the document styles feature and the file combining plugin. While I'd rather they'd implemented both of these features differently, it may be that this is only phase I of a longer-term plan for these features to make file and style management a lot easier. Add to all these internal codebase issues the external dependencies on OS X (with its shifting APIs) and Windows (with it's new versions with major revisions to how apps work), and it becomes pretty complicated to get anything significant done in a mere year of coding. All that said, I wish they could do better. But I understand why they sometimes miss the mark. -- David W. Fenton http://dfenton.com David Fenton Associates http://dfenton.com/DFA/ _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
