Interviews

Interview by Jari Williamsson, February 2005

What's your background?

I have a bachelors and masters degree in Violin performance.  After finishing my Masters degree and spending a year working as a freelance musician, I decided to go back to school and complete a computer science degree.

How long have you been with the company?

I've been with MakeMusic for just over 8 years now.  I previously worked at 3M here in the Minneapolis area as a software engineer.

What is your job at MakeMusic?

I started at the company as a software engineer, working on Finale.

Now, my official title is Manager, Notation Engineering. That basically means that I manage both the notation application projects and the engineers who work on them.

Do you use Finale "outside work"?

I don't really use Finale outside of work. Since my background is performance rather than composition I was never much of a Finale user before starting here, although I did have a copy of Allegro that I had purchased a year before starting here.

What involves being the project manager for Finale?

As the project manager for Finale and the other notation products, I spend a lot of time working with people from other departments to coordinate our efforts and get products out the door.  I work closely with the Development team, Marketing, QA as well as the Executive Management Team, to define the features for a release and to balance that feature set against the development time we have.

As the development work starts, I lead the engineering effort by trying to keep the path clear for the engineers and make sure that they have what they need to keep moving ahead.  In addition, I coordinate with QA to ensure that we are getting them what they need to make their testing as efficient as possible, and to ensure the engineer's testing priorities are clear.  This allows us to uncover issues as early in the cycle as possible.  All of this includes time spent reviewing and prioritizing test and bug reports, tracking work against our development schedules and reporting on the team’s progress.  I do still dip in and do the occasional bug fix, but not very often these days.

I guess I see my job as a juggling act of making sure that we don't lose sight of the big picture and as all the details come flying in from multiple directions; while at the same time, making sure that these details are taken care of.

In what ways is the development of the smaller Finale "sibling products" (PrintMusic, Notepad, etc) related to the Finale development? Is the same set of engineers used for all notation products?

The children, as we call them, are pretty much subsets of Finale. This means that the development is more a matter of blocking off features than designing new features.  They are all built off the same code base so in a sense all the engineers work on these products.  Generally, there are one or two main engineers doing the vast majority of the work.  As can be expected, when testing PrintMusic or Allegro, QA will find bugs that are also in Finale.  If these are bugs which need to be address for the children, that work might well be done by another engineer in the context of Finale and then inherited in the child product.

Which are the differences in development efforts between the different notation products?

The biggest difference between working on the children and Finale is that the children don't usually have new features.  On the plus side, as I learned when I was a new engineer at MakeMusic, it is a great way to quickly get an overview of Finale and all the pieces.  I did the second release of Allegro back in 1998; it gave me a terrific sense of what Finale has to offer.

Does your job include decision-making on how a feature should be implemented (on a technical level)?

It could in some cases, but in general no.  I prefer that these decisions be made by the engineer doing the work or by the whole engineering team when a feature has larger architectural implications.  Especially on larger features, an engineer will come up with a design that can be reviewed by the team as a whole.  It is always best to have multiple sets of eyes work through a design.  This gives us the opportunity to take advantage of each person’s perspective.  But if there are differences of opinion as to how best to implement something, I like to defer to the engineer who did the original design.  The only exception to this would be if the team felt strongly that the engineer was taking Finale in a totally wrong direction.  But honestly, I haven't seen that happen in my time here.

How is the feature set for a future Finale version defined?

There are a number of sources for new features each year from external and internal sources.  One thing I learned very early is that there is never a shortage of new ideas for Finale features.

Starting with a rough list of ideas we prioritize them based on how they fit market needs and wants as expressed by our users, how they fit with Management's plans for future directions, and how they line up with engineering and QA resources.  We also make an effort to balance the feature set for different groups of users.  We try to make sure that every upgrade has value for all of our users, from the professional engraver to the high school band director.  While there is always some overlap, the appeal of a feature for these two groups will be very different.  For example, if the main features are aimed more at educators, most of the small items will be aimed at the high-end power user.  For each release we target one or two large feature areas.  In addition there's always a working list of smaller features which we add as time permits.

In what ways do you get feedback from Finale users?

We get feedback in a number of ways both from customers who contact us and customers we contact.  We have a lot of customers who contact us directly, usually through Customer Support, by phone, email or the Finale forums.  These users are often looking for technical support, but also often share their ideas on how to improve Finale.

Marketing makes a huge effort to connect with users and learn what they need.  Much of this interaction is through workshops on our products, trade shows, and the occasional direct survey.  In addition here in development, we get direct feedback on new development from our beta program.

You release new versions of Finale on an annual basis, does that mean that the implementation of a new feature always have a "time limit" of less than a year?

Yes and No.  Obviously some features take more time than others to implement.  If something takes more than a year and the value of the feature for the user is high enough, it will be phased in.  The selection tool is a good example of this.  The first year most of the work for the selection tool was not visible to the user.  It wasn't until the second year's development that the real power started to be seen.  We always take future development and enhancements into account as we design a feature.

Why do you change the Finale file format in every new Finale version?

With any new feature, we need to add new data to the file to support it. We always supply a path to convert old files into the new format, but moving new files into an old format is not so easy or satisfactory. While it would be possible to "reverse convert" a file, the result would never be as good as having created the file in the earlier version in the first place.  Plus, the engineering effort to maintain this would mean fewer new features every year.

For example, with the changes to tuplets last year we needed new flags and to reinterpret some data structures.  If we allowed users to save a Finale 2005 file in a 2004 format, any tuplets in the file would have pretty poor placement.  Underlying this is that there really is no way to make a 2004 file have tuplet placement as good as a 2005 file without a lot of manual adjustment.

Luckily for users who really need this compatibility and are willing to sacrifice the enhancements in the newest version, we now ship with MusicXML Lite.  This plug-in will allow users to move the bulk of the data between the last few versions of Finale.  While it still has the limitations of never making an earlier version of Finale support things it didn't when it shipped, it does at least get much of the data back into an earlier version for editing.

Who communicate with the documentation editor? Is that the job for the developer working on a specific feature?

It depends a bit on the feature.  In general the user documentation will start from the design documentation.  Where this documentation is not sufficient, the missing pieces will be filled in by both the QA leads and the engineers working on the feature.  All the user documentation is reviewed by QA as part of the testing process.

How do you look at the future of Finale?

I think Finale has a very bright future.  I admit, I may be biased, but I think that the quality of the people at MakeMusic, from the development staff, customer support, sales and marketing, right through to the Management team all speak to an exciting future.

But what probably speaks best for Finale's future is the passion of our user base.  When I talk to people who work at other software companies, they are often amazed by how much contact we have with our users.  It is this contact and their passion which really keeps us on our toes and working to meet their expectations.  It's not easy with so many differing opinions about what directions we should be going, but it is also what makes it rewarding.