Interviews

Interview by Jari Williamsson, January/February 2005

What's your background?

I graduated with a degree in music composition from CCM (College Conservatory of Music) in Cincinnati, Ohio. I taught myself computer programming in the early '80s (later supplemented by some classes).

When did you start in Finale development?

I came on in June of 1989 to pick up the Windows porting project, which had been under development for a year at that point. The original developer was moving to Germany, so I was lucky to be in the right place at the right time.

How would you describe the evolution of Finale during these years?

From the user's perspective, Finale has gotten faster, more stable, and easier to use. From the insider's perspective, the code is far better -- better design, more rigorous, much tighter. We moved the codebase from C to C++ in the early 90s, which helped a lot.

There are very few places in the code that haven't been totally reworked over the last fifteen years. That doesn't mean there is nothing left to do -- there certainly is! But we have come a long way.

Finale was originally designed by a brilliant but -- shall we say -- undisciplined programmer named Phil Farrand. I worked with him over my first few years at the company while we worked to bring the Windows version up to par with the Mac. I have no end of admiration for Phil -- his brilliance is matched by a kind of fearlessness, willing to try the most daunting tasks, projects most of us would say are simply too hard.

But Phil was entirely self-taught as a programmer, and had never worked with any other programmers, which led to a rather eccentric coding style. But once I could see what he was doing, I realized how amazing this thing was, this thing he had created called Finale.

Do you use Finale yourself (apart from programming)?

I have done half dozen or so large orchestral projects over the last ten years. Sometimes I find it difficult to try to work with Finale rather than on it -- when I run into issues it is hard to resist the impulse to fix it right there on the spot! I always keep a list of things I run into, to be addressed at another time.

So I'd say I have a pretty good view of Finale as a user. In fact, many (if not most) of the Finale team (programmers, QA, tech support) are Finale users as well. (And, by the way, quite a few are gigging musicians also.)

As a Senior Finale Developer, what is involved in your job?

I do my share of feature design and development, as well as bug fixing. My depth of experience helps me be a resource for the rest of the team as well -- helping new team members get up to speed, giving advice based on my knowledge of internals, pointing out potential trouble spots in new designs, etc.

What would you think would define an "ideal" programmer for Finale?

Besides programming chops, the more music knowledge the better. On the programming side, we tend to be very self-reliant -- usually we are involved in everything from conception through design through coding through testing. Yet at the same time we have to temper that self-reliance with being able to work as a team.

When you develop a new Finale version, what's generally the most discussed issues during the planning phase? Feature set? User interface? Compatibility with old behaviour? Other issues?

All of the above? <g> No really, it can be quite a juggling act, esp. when goals conflict. For example, it is a fundamental rule that a new version should not change the output of an older file. But what happens if the output was wrong before and looks different now because of a bug that was fixed, or a feature that was improved? Sometimes we have to break one fundamental rule in order to follow another.

The same sort of problem happens when changing the UI. As much as we may think we are improving it, some people may happen to like the old UI, even if it was clunky and confusing to other users. And believe me, people will let us know when they don't like a change! So how do we balance the needs of a vocal minority against the needs of all other users?

Usually the design of a new version begins with what kind of new features we want. We build a long list of desired features, compiled from our own experience, user requests, features that fell off the table in previous cycles, marketing's requests, and new ideas (things nobody has asked for because they don't know they need it yet). Each item is ranked by the (1) how useful is it? (2) how much of the user base will it appeal to? (3) will it attract new users and increase sales? (4) how difficult is it? and (5) how many resources will it require? (not just programming time, but testing time and documentation time.)

We might find that one proposed feature would be tremendously useful to a very narrow portion of the user base, or that something might be moderately useful but very difficult to program, or that something is easy to program (doesn't require complex algorithm development) but will still take a lot of time.

I like to think of a new version as a glass jar that we are filling with features. We can put a few large features in, like several large rocks, but only so many. But is the jar full yet? No -- we can add some smaller features like small pebbles between the larger rocks. So is it full yet? No -- we can still add tiny features like sand between the pebbles. So is it full yet -- no, we can still add water!

Personally, I think the small and tiny features taken as a whole can easily be as important as the large features, and so are a vital part of the design process.

Regarding users who don’t like a change: isn't this more of a documentation problem than a software design issue? Isn't the main conflicts caused by the fact that upgraders think everything works as before - because they didn't receive any information about any interface change?

I think we could be better about documenting changes up front, but the fact remains that people tend to resist change, and people also tend to not read documentation!

How do you (as part of the programming team) get feedback from users?

For years I followed the SHSU list quite closely, as well as our own Finale forum. I have to admit that lately I haven't had time to follow them as closely as I had in the past, but it remains a primary source of feedback.

Actively participating in the forums can be a tricky problem. For one thing, we can't discuss current development projects, nor even hint as to their nature. So when someone says "why don't you do this?", we might actually be working on it, but can't say so. And yet silence or a vague reply can be taken as a rebuff, leading to accusations of "not being interested in what users want".

So I spend most of my time on the forums just lurking. When I feel that I can answer a question, I try to do so anonymously, so as to avoid these types of conflicts.

What development tools do you use?

We are currently using Visual C++ for Windows and CodeWarrior for the Mac. In addition, we have various tools such as source control (we are using CVS at this time). Also, I prefer the CodeWright programming editor to the Microsoft one. Bug reports and feature requests are tracked in a database.

Did I mention that I tend to focus on Windows? Although we all program in a cross-platform way, and are expected to compile and test on both platforms, we each have our own preferred platform.

If I remember correctly, you moved to MFC ("Microsoft Foundation Classes") around Finale 2000? Looking back, what have been the troubles/benefits with using MFC in Finale?

The important point was realizing that MFC had become the de-facto API for Windows development. We could continue to program "down to the metal", but that would make it more difficult to incorporate new UI elements, or to take advantage of UI solutions from outside vendors. Even now, we only half-exist in the MFC world. Our document-view architecture, for example, has evolved in a cross-platform way, and doesn't correspond exactly to MFC's view of things. Yet this is necessary to retain platform independence.

How are cross-platform issues solved in Finale?

Since we evolved a stable cross-platform architecture we haven't had to deal with many cross-platform issues. Core solutions are usually cross-platform from conception. What this does mean, however, is that we often must eschew the flashiest new UI features offered by the OS. This isn't just a problem with Mac vs. Windows, but also between different versions of Windows and different versions of OSX. We are hoping to be able to make more use of such UI innovations in the future, while remaining flexible about platform and OS. We may choose, for example, to implement a new feature that simply won't be available on Windows 98.

Are cross-platform issues a major concern when a new feature is designed?

Mainly that we want to keep the platforms as similar as possible.

Can you describe the background to the plug-in programming interface  (that was first introduced in Finale 97)?

This was an idea I had been toying with for several years. It had become clear that there was no way we Finale engineers could ever provide all the features that people wanted, esp. the more obscure ones. I was able to sell management by providing a proof-of-concept demonstration.

Since then, have plug-ins affected the development of Finale in any way?

One curious fallout over the years has been that sometimes I have to argue against a plug-in solution to a particular problem. There are some things that Finale simply must be able to do natively, and solving the problem via a plug-in is a second-best solution. So if anything, plug-ins have been so successful that sometimes we have to rein back and consider whether a plug-in is really the appropriate way to address an issue.

But on the whole, I think there is no doubt that the plug-in architecture has been a tremendous benefit to Finale.

How do you look at the future of Finale?

We want to keep Finale as the leader in music notation. Yet we are aware that the music notation market per-se is very limited, so we have to look at ways to broaden our appeal without sacrificing the quality or integrity of the product. You have seen evidence of this in our offerings to the music education community.

Another way to broaden our appeal is our continuing effort to make Finale (and its children: PrintMusic, Allegro, etc.) easier to use, again without sacrificing the underlying power.

Finally, we have terrific technology in the SmartMusic side of the business. I would hope to see more sharing of technology between SmartMusic and Finale.