In the nerve-centre: How I choose what goes into each release
April 08, 2011 in bliss by Dan Gravell
bliss releases occur every fortnight. The general process is: I build a beta of all the latest new features and bug fixes, it goes into beta testing for a week and then gets released.
So each release contains new features and bug fixes. But how do I choose what work goes into each release? It's not straightforward; there are always things I want to change and improve or cool new features to add. Overriding those is the requirement to fix bugs before writing new code, so when a customer gets in touch to tell me of a bug this always takes priority (this has been happening less and less, thankfully!). In a way, this is frustrating, because all computer programmers enjoy working on new stuff. The reality, however, is that I am paid by customers and I need to make a living. The addition of features with the intended promise of long term success has to be balanced by improving reliability and polish, which helps drive short term sales and keep a roof over my head in the meantime!
To help me choose work for each release I decide on an overall theme for each fortnightly release. This is very much gut instinct. For instance, with the release I'm currently working on (the one following the first genre organisational release) I decided to concentrate more on polishing the new genre features and other small improvements. After deciding on the theme, I choose at least one piece of work from each of three 'streams'. By doing so I hope to achieve balance between retaining short term sales and improving the vision and future for the product. I've come to giving each stream a name; 'polish', 'UserVoice' and 'strategic'.
The first stream is 'polish', within which I count bug fixing, small user interface improvements and anything that does not add functionality, but makes the functionality work better or easier to use. I think this type of work is important to maintain sales levels and making sure bliss is doing a good job for existing customers. For instance, I might notice that when clicking a button bliss takes a long time to respond, which can be confusing (did I click it? Shall I click it again?). Rectifying such a problem is considered polish.
The next stream is 'UserVoice'. This is totally driven by the bliss feedback forum. Each item in the list is a possible item I take into a release. I pick at least one item, depending on the number of votes the idea has had and the size of the idea in relation to how much time I would have to devote to it. Also, some ideas will take several releases to complete, so sometimes in addition to completing one UserVoice item I might also take in some preparation work to make another item easier/quicker to implement. The UserVoice ideas are more medium term. By adding features I can expect to attract more customers in the medium term as bliss can solve more people's problems. Work which further improves the UserVoice ideas are considered polish.
The final stream is 'strategic'. This is any work implemented to improve or reduce risk to bliss in the long term. Some major user interface improvements are categorised here too. An example of risk reduction I have been working on recently is Internet based lookup of music information, including album art. Right from the start, bliss has used MusicBrainz and Discogs for these purposes (actually, Discogs is only used for art right now, but that should also change in the near future). If one of these services was to disappear, or they changed their access terms and conditions, it would have a great impact on bliss's functionality. Therefore I have slowly been reducing this risk through new features (such as using Wikipedia to search for music information) and also less obvious changes (for instance: the new online album art cache where users of bliss share album art results, thus reducing the strain on the online databases).
All three streams are interconnected, and I think work trickles down through the streams over time. Consider this: new work that is implemented for strategic reasons which may not have been discussed in the UserVoice forums generates interest and develops the way we all think about the product. This leads to further new ideas suggested on UserVoice, both improving the new feature but also generalising and applying the strategic feature to other areas. Then, once these new UserVoice ideas are implemented there may be further UI improvements to the work that's done as polish, and so on.
I hope this behind the scenes look at how I choose what to work on has been enlightening!
Thanks to Victor Bezrukov for the image above.
