For those of you who don’t know, my background delves into the musical realm. I played piano for six years and trumpet for twelve. One of my first musical memories was the Pac-Man notebook in which my piano teacher wrote my very first week’s assignment. After a childhood mixed with software development (the first PC my father purchased for personal use was an Epson QX-10) and music, I’m presenting for you today 10 ways that writing software is like performing music.
1. The difference between good and great is subtle
In music, a small intonation or tuning issue can make or break a complex passage. If musicians don’t adjust for the condition of their instrument while playing the instrument, such as adjusting the pitch as the metal of the trumpet warms, the instrument can become out of tune. With software, detail matters, from the design to the number of clicks it takes to perform a task. Good software lets people do everything great software does; great software does it more elegantly. Customers love good software until great software comes along.
2. Without a solid foundation, the best performers and coders cannot reach full potential
When performing music, if the score is bad, even the best performers won’t sound great. They can add their special touch to the music, but the performance won’t be as great as when the score is superb. In software, if the application has improper architecture, the wrong programming language is used, or a variety of other maladies, the best developers have less of a chance of producing the best software (though some still can).
3. If anyone in the team fails, the result will not be great
If the 2nd chair tuba is having a bad day and misses a key section of music, the whole orchestra is affected. If QA fails to find critical bugs or the deployment team misses an important file, the experience to the users will be broken. Everyone’s efforts are important to the team as a whole.
4. Without overall coordination, efforts are wasted
The conductor is responsible for result of the orchestra and guides everyone to improvement by providing feedback that performers otherwise would not be able to self-ascertain. The musician can listen, but cannot always accurately determine the effects of their work to the orchestra as a whole. If none of the performers have sheet music, random notes from everyone in the orchestra will result in noise. Efforts must be aligned. In software, a product manager drives the vision and guides the developers to create software that amplifies the effort that was expended. In both cases, alignment is necessary to push everyone in the same direction. If developers are moving in different directions, the product will be disjointed and misaligned and the company’s goals will likely not be reached.
5. When you’re done, there is always room for improvement
Think your code is done once it’s live? Think again. There are always ways to improve. The end user experience could be improved, code could be refactored, or the database could be used less. After listening to a recording of a concert, the orchestra might find they could crescendo more quickly, the dolche passage could be more performed even more sweetly and softly, and so on.
6. Finishing with a remarkable ending leaves the audience or users feeling happy
A hat tip to Kathy Sierra and her talk at the Business of Software 2009 conference for this idea. Think AC/DC and their classic concert encore performance, “For Those About To Rock“. Done properly, it gives the audience a very memorable finish. In software, it’s slightly different, but the concept is the same; there are many end points, but all of them should leave users happy. Think of what your users are trying to accomplish, and make the results awesome, whether it be a polished music player, a report that looks highly professional but was created with three easy clicks, or whatever it is that your software does. There can be many of these “results” in your product, but they all should leave users feeling like they did something incredible.
7. Listen to what your audience or users have to say, but don’t do exactly what they say (most of the time)
Using a band that takes requests from the audience as an example, the band members can take suggestions from the audience, but they’re just suggestions. Five requests for a song of a specific genre or artist might be a hint to the musicians to play one of those songs or at least one that is similar, but the musicians can decide. Similarly, if your band’s audience loves a particular ad-lib solo or memorable on-stage antics, perhaps it should be done again at another performance. In software, directly implementing customers’ ideas might not have your product’s best interests in mind. Often, it’s better to absorb many suggestions, then create features that address many customers’ needs at once to get more value from fewer changes. After all, developer resources aren’t unlimited. Related to this, it may be useful to monitor when and how much your customers use each feature in your software, and if they don’t use it as much relative to other features, maybe it needs improvement. Listening to users doesn’t always mean answering the phone or email.