Sight-reading a Software Project
A musician sight-reads a piece when they play it from the sheet music for the first time. Depending on their experience level and the difficulty of the piece, sight-reading can have mixed results. This variability in quality is extended considerably when an entire ensemble attempts to sight-read a piece – key signature changes can be missed, players can miss entrances, etc.
While sight-reading is an important skill for musicians, it is not the deciding factor in the quality of their playing. For an ensemble, it’s almost assumed that the first read through a piece will be a bit of a throwaway, used to understand which areas of the piece will require the most work.
I’m far from a professional musician, and the community band I play in sight-reads pieces with variable success. However, in my time with the group, I don’t think we’ve ever abandoned a piece due to challenges in our first run through. As a clarinet player, extended sixteenth note runs in the upper register simply elicit a quick laugh, and a collective “oh boy, this is gonna take some work”. While challenging, if a piece doesn’t ever warrant such a response, it’s bound to be a bit of a bore.
The confidence to look at a section of music that’s too hard for a first read but is still conquerable is a learned skill. And to be clear, not all pieces can be played by all ensembles. A fifth grade band likely should abandon Shostakovich’s Festive Overture after a disastrous sight-read.
In preparation for a new concert cycle (we typically run a concert every 6 weeks), my favorite rehearsal is the second. In typical S-curve fashion, the second rehearsal represents the steepest section of the learning curve. By this time, the basic issues are all worked out, and we can begin getting into the weeds of the subtleties of the music.
A typical S curve
In my day job, I’m approximately as skilled at building software products as I am at playing the clarinet, which is to say, “at least ok, not an active detractor from the effort”. Our last 6 months getting our product off the ground have been an extended sight-reading effort, with the following major issues (each of which warrants a blog post by someone on our team, and yes, there are many more):
- Attempting to port the UI to iPad, and abandoning the effort after determining that the effort would be unlikely to pay off
- Intermittent outages that have been hard to debug due to an absolutely horrific monitoring setup
- A bad login system that caused major confusion and ongoing issues with one of our first pilot customers
These issues, while annoying, are not the equivalent of playing Shostakovich for elementary schoolers. They’re more of the sixteenth note runs in the upper register. This is good news, and better yet is that our team is moving into the equivalent of our second rehearsal. With more information about the challenges of running this particular product, we’ll be able to make the required changes to make something pretty nice.