Starting with this release, we’ve made a slight change to how we deliver release-branch builds: we’ll be calling out specific builds off of the release branch to focus attention on, instead of having every nightly build published.

We’re making this change for a couple of reasons:

• Reduce churn on incoming issues that are known, but which need to then be triaged and percolate through the development process.
• To point developers and users to builds we know are worth looking at; we want to help focus the precious testing time our development and end-user community donates to looking at bits that are more “known quantities,” so they’re not frustrated with issues that are both known and which we’re actively working on fixing during release cycle.

This change will not affect source code availability via publicsvn; developers will still be able to pull release branches and build from source.

Additionally, builds from trunk and project branches² will also continue to be provided nightly³.

When we do have release builds that you’ll want to look at, we’ll publish betas via the Nightly Builds page, just as we always have.⁴

Enjoy the (clearer) birdwatching!

________________________
¹ The release may—or may not—smell like Teen Spirit.
² Such as the GStreamer Integration branch
³ At least, as long as there’s a check-in for that day
⁴ For those who have birdwatched forever, we may even bring back “blessed builds” when it makes sense to do so!

All the Media View developer needs to do is create an icon file.  It must be 22×80, with all four 22×20 states (normal, hover, active, and disabled) vertically stacked in it.  Here’s a sample one I created for John M’s excellent Grid View:

All that’s left is to point to it inside the Media View’s install.rdf file.  In the same <songbird:mediaPage> section we simply define a new <songbird:contentIcon> value, like so:

<songbird:mediaPage>
   <Description>
        <songbird:contentIcon>chrome://gridview/skin/mpIcon.png</songbird:contentIcon>
        <songbird:contentTitle>Grid View</songbird:contentTitle>
        <songbird:contentUrl>chrome://gridview/content/media-page.xul</songbird:contentUrl>
    </Description>
</songbird:mediaPage>

That’s all there is to it!

I just committed an encoding fix for Songbird’s Concerts add-on that, starting with tonight’s nightlies on trunk, should mean you start seeing some updated European countries in the available locations list.  The new countries include Denmark, Finland, France, Germany, Netherlands, Norway, Spain, and Sweden.

While the concert data is now being included, not all localisations are up to date.  Notably, out of that list, we’re missing the Danish, Finnish, Dutch, and Norwegian localisations entirely.  The Swedish localisation just needs a few more strings translated.

If you’d like to help out and see the full localised Concerts add-on in all its glory, please go register with Babelzilla.org and help translate the Concerts add-on here.

Fortunately, the metrics gathered during each Agile release cycle can be very helpful for that purpose. Once we gain a good understanding on what is being worked on, for how long and by how many people, we should be able to extrapolate this to forecast future releases.

Let’s take a look at what activities take place during a typical release cycle:

1) Plan release
2) Write code
3) Test
4) Fix bugs

Then repeat ad nauseam.

In that context, the programming tasks can be categorized as follow:

1. Planned work

This is the body of work identified during the planning stage. This is the raison d’être of the release. For the most part, this covers new features or less tangible things such as performance improvements. This is what we’ll want to talk about when the product gets released. It’s an easy planning trap to think that this is the only work required.

2. Unplanned work

As the name implies, this is work that was unforeseen at the beginning of the release but is required to be completed before the product can ship. It can be further refined as follow:

a) Change in requirements
This should not be unexpected. In fact, any Agile methodology assumes that there will be changes down the road. This is not a problem per se as long as there is a mechanism to trade features, extend duration or increase resources.

b) Omissions in planning
Because the planning period is relatively short, it is assumed that not everything is fully specified or researched upfront. As development proceeds, new pieces are discovered and introduced into the plan.

3. Bugs

Defects can be considered a side effect of software development. They can affect the product in different ways:

a) Regression
These are defects introduced when working on new code. They usually impact unrelated functionality that used to work before.

b) Defect in new feature
These are problems in a newly coded feature. The feature does not work quite as expected.

c) Existing bug
These are bugs present in the previous version of the software. They are either known or newly discovered during the course of the release and prioritized to be fixed now because they affect existing users.

Learning from the past to project in the future

A believable long term plan needs to layout new features on a timeframe against a set of resources. Because there is only a limited amount of time and people allocated to thinking through the issues upfront, the initial estimates are always very rough. It is then very difficult to predict how much time certain things will take or how many people will be required. To increase accuracy, you’d have to invest more time and resources, which is not practical, mostly because these are the very same resources that are critical to deliver against the current release plan.

You need a model to help forecast based on imperfect data. You could decide to simply pad all the current estimates, but you’d still need to figure out a factor that’s sufficient.

A better model is to find a way to anticipate the additional work that will be generated by the introduction of a brand new feature. With that model, we can layout a plan that should allow sufficient room in every release to accommodate for all the work, planned, unplanned and bugs.

Let’s take a look at historical data from previous Songbird releases:

The first row in the table contains the budgeted points for each release. That number represents the sum of all planned work as determined at the end of the planning phase for that release. The release schedule was set based on that number and the historical team velocity.

The second row represents the total actual points completed during the release, including features and bugs. This represents that amount of effort to get the release out.

The third row represents the actual completed feature points only. Next row computes ratio of planned vs. actual work.

It’s very tempting to compute a velocity based on total completed points and use it as a predictor for how much work the team can accomplish. While it’s true that it is a measure of total effort, it can’t be used against planned work only.

What we want to determine is that given 1 point of planned feature work, how much unplanned work and bugs will be generated and thus how long will it take to complete. Then normalize this for team size and you get a factor that can be used for long term planning.

To get there, I’ve computed a velocity for each release based on planned work divided by actual release duration (in days) and number of engineers. I then use the median value across release as a factor to turn estimated planned points into calendar days. With that in hand, I created a simple model where scope, duration and resources are linked. Set two values and the third one gets computed automatically. This model becomes very handy to run through what-if scenario during roadmap sessions. It provides answers to business questions such as: “How long would it take to do feature X?”, “Can you meet deadline Y?”, “How many more engineers would it take to do Z in Y time frame?”.

Hope you enjoyed learning more about our approach to the difficult task of long term planning. I’d be interested to hear about how you’ve approached the problem, so feel free to share your story.

Lastly, let’s remember the words of the famous Danish physicist Niels Bohr:

“Prediction is very difficult, especially if it’s about the future.”

Songbird Release Trains

We concluded that a dashboard that was more dynamic and worked in real time with Bugzilla would provide a more accurate picture of development progress. This is an overview of the couple of extensions we added to the tool.

Dashboard

The dashboard focuses on the current iteration (all P1 stories/tasks/bugs for a release target milestone). It provides a transparent and dynamic view of what’s under active development for the week.

Items are grouped by developer so we can easily review what each person is working on in this iteration. There are few additions that make it more useful than a plain Bugzilla query. When an item is carried over from a previous iteration, it gets highlighted, providing visibility on something that may require more work than anticipated or might be blocked by some dependencies. That kind of view was lacking before and it made it difficult to figure out what was happening when tasks got carried over. Similarly, when a new task gets added to the plan mid-iteration, it’s identified as such, making the tracking of intake very easy.

Because of our code review system, often time tasks are completed from a programmer standpoint but can’t be checked in until a positive review (R+) is performed by someone else. Additionally, some code requires the re-compilation of large amounts of 3rd party libraries before the patch is available. This kind of information is now bubbled up on the tracking page so the exact status of a particular issue is visible at a quick glance.

Iteration Dashboard

This dashboard is helping us to know what everyone is doing at any given time. It fosters a sense of accountability and ownership of the issues and provides a sense of accomplishment when the work is completed.

Below is a view of the legend for the Dashboard. Most attributes for an item are extracted from Bugzilla and represented via an icon.

Dashboard Legend

Punchlist

Once a release reaches QA, a release branch is cut and the focus of the team switches from working on planned features to fixing bugs. We found that this period is best managed by using a punch list which contains all the issues remaining to be resolved before the release can ship as opposed to a weekly plan of what gets accomplished for the period. It keeps the team focused on the entirety of what’s on our collective plate. During that period, issues are being promoted to Blocker status to represent what is blocking the next milestone (e.g. Beta, RC, Final). It also signals what can be landed on the branch automatically and what needs further clearance. This allows us to throttle the rate of change being introduced into the source tree so that QA can be ensured stable builds.

Release Punchlist

When in punchlist mode, it’s critical that all issues are being assigned. The list reflects that by highlighting items that have no owner yet.

Pretty Graphs

Two frequently tracked Agile metrics are Burndown and Velocity. Those are now being graphed automatically for each release. The Burndown helps forecast when the work will be completed. The Velocity gives us a historical perspective on what the team was able to accomplish and thus helps us plan better.

The Burndown graph breaks down tasks (what we refer to as “planned work”) from bugs (unplanned consequences of software development). When the Burndown line cross the horizontal axis, we’re done. Notice in the graph below the bug points going up during the QA period.

Burndown Graph

The Velocity graph plots the team velocity, normalized per day. Actual Velocity is computed at the end of each iteration and plotted along side the Planned Velocity for easy comparison.

Velocity Graph

These new tools provide a dynamic view of the state of the release. They bring transparency into the development process for everyone involved.

If you’re impatient, or raring to grab the update, go to Help > Check for Updates in the Songbird menus to trigger an update; this will download 1.4.3 in all its purple glory!

We know some of you prefer the Gonzo Feather. Thankfully, we have an awesome community developer and Songbird Champ: boosh. He went ahead and made a Gonzo 2.0 Feather using all the UI enhancements we made in Purple Rain, but with the visual style of Gonzo.

So for those among our flock who find purple distracting, you can still have your Korn cake with Gonzo, too!

Enjoy!

(1.4.1 and 1.4.2 users will also get an update prompt to 1.4.3.)

As you know we’re big believers in openness and as such we try to share our development plans and progress with you as regularly and freely as we can. This isn’t as straightforward when other companies are involved — especially large, global, public companies like Philips. So we apologise for not being able to talk openly, sooner, about this new relationship but we hope, even as a bit of a surprise, you can appreciate why this is a good thing for the company, the products, the platform, and all of our users. As always we’ll strive to give you an early heads up whenever we can.

While there’s obviously some special work we’ll do for Philips, we don’t think about this as one-off work. Much of what we do for them, is work we’ve been planning to do for all Songbird consumers. For Philips, there’s certainly a custom feather and the add-ons that are important to them and their customers. We’re working to make sure that all of what we build is valueable for you and for partners … with as few exceptions as possible.

Our partnership with Philips is a great step for us — it drives distribution, revenue, and an even tighter connection to the CE side of the world. Of course the partnership means more features to consider and tradeoffs to balance – but in this case, that’s a great problem to have. There is lots of overlap in desired features from both sides, so this probably means you’ll see some things accelerated, which is good news for all Songbird consumers. We know that users around the globe using the software and sending us their ideas ultimately results in a better experience for everyone. So keep your suggestions coming.

There’s no resting on this week’s milestone achievement, we’re working fast and furiously on the next release, which will hit early this year. Stay tuned for more as we move continue evolving plans and working through development.

Thanks again for all of your support!

we’ve been following the blog comments, reading the bug reports, and getting the feedback from GetSatisfaction bubbled up to us via our intrepid Songbird Champs.  there have been a few recurring issues worth mentioning/recapping, so here we go in no particular order:

1. Windows 7 Support
   • Yes, we throw a warning message up when you’re installing Songbird regarding it being unsupported on Windows 7.  This is mostly a “caveat emptor” warning, we haven’t done full and proper QA test runs to ensure things work on Windows 7.  That being said, we have plenty of users who run it just fine on Windows 7.  If you do continue to install and run it on Windows 7, you may experience bugs.  We’re working on full and proper Windows 7 support for the next release if you want to wait.
2. iPod Support
   • As mentioned previously, we are no longer maintaining the iPod Extension.  Continually playing an unsupported game of catchup with Apple sucked, and we’ve opted to go with iTunes Import/Export Syncing as our supported way of having users sync their music libraries with Songbird.  As mentioned in that blog post, we’ve open sourced the iPod Extension (which is built on libgpod), and would happily welcome any community patches to it.
3. Splash Screen
   • Yeah, we get it.  Some of you don’t like the splash screen.  Unfortunately it does, believe it or not, serve a purpose.  Not everyone has the super-latest-OMFG-ITS-1BILLION-TERAHERTZ machine… and especially on some platforms (Windows XP for instance), there was no feedback as to when the application was starting.  If you really really really hate the splash screen that much, then go grab Simon’s splish splosh extension to easily change or disable the splash screen.
4. Bookmarks
   • Over the next few releases you’ll see us phase out some of the more web browser specific features.  This is a conscious design decision to differentiate Songbird as more of a media player than a web browser.  Let’s face it, we’ll never be a better web browser than Firefox, Safari, or Chrome.  We’ve never intended for Songbird to replace your daily web browser.  Don’t take this to mean we’re removing the web browser component entirely… we can’t, and we won’t since we use this for rendering things like the Last.fm Radio Directory, the 7Digital Music Store, the Concerts Listings page, etc.  It just means we’d prefer for add-ons to take a more integrated approach along the lines of the 7Digital, Concerts, SHOUTcast, & Last.fm add-ons where servicepane nodes are displayed that link to custom chrome (or heck even to webpages tailored specifically for Songbird, such as the 7Digital store).
   • That being said, if you really really really want your bookmarks back, I’ve made a Songbird Bookmarks extension that re-enables the bookmarks servicepane node so you can get your old bookmarks back.
5. Automatic Album Art Fetching
   • One of the new features in Songbird 1.4.3 is automatic album art fetching.  Depending on what mode you have album art in (either “Now Playing” or “Now Selected”), album art will be automatically fetched for the currently playing or selected track.  If you’re on a slow or high latency connection (and this can vary depending on your album art fetcher add-ons and priorities, set via the Album Art preferences), you may experience a lag when selecting or playing tracks as Songbird goes to fetch the album art.  We’ll work on improving the performance of this in the future, but for now – I’ve made an extension to allow you disable or enable this automatic fetching behaviour.

Just want to download it?  http://getsongbird.com is for you.  Waiting for your automatic updates?  We’ll post ‘em later today (Tuesday in the US). See the 12/23 update below.

(Kanyebird is gonna let you finish, but he thinks the Gonzo feather was the best feather of all time.)

Update (12/23/09): The Gonzo feather really, really did not want to go away; we fixed yet another Gonzo-related bug (number 19365, if you really want to know) and released Songbird 1.4.3.  Automatic updates will come out early next week.

Songbird 1.4.1’s main focus has been on adding new device support, CD rip support, and a new Feather/skin. We’ve included more format/codec support out of the box, improved the media management user experience, and continue to work on performance, footprint, and stability. We continue to listen to your feedback on Get Satisfaction, Bugzilla, and of course right here on our blog. Please let us know what’s important to you.

New Features

MSC Device Support
Songbird now supports MSC (Mass Storage Class) devices. Sync tracks (and playlists on compatible devices) to phones and other MP3 players with MSC mode. Tracks in incompatible formats can be transcoded on the fly to ensure your music is always with you. (Windows only, requires the MSC add-on)

CD Rip Support
Songbird can now rip CDs! Automatically lookup your metadata on Gracenote (or other third party services via additional add-ons), and rip CDs to FLAC/OGG (or WMA on Windows). (Windows only, requires the CD Rip add-on… Mac support is coming in the next release)

Purple Rain Feather
OMG! New Feather! We’ve designed a whole new Feather for a whole new unique look. Dedicated toggle buttons for the most frequently used Media Views, simplified and more obvious Display Pane management, and a unique look all to our own.

For more info on the release, please see our release notes.

What’s Next

Our next release will introduce video management and playback, Windows 7 support, continued UI work, and more performance/stability work. Stay tuned to the blog to keep up to date, or if you like to live dangerously check out one of our nightly builds and see the progress for yourself!

We’re always interested in hearing your feedback so please comment below and file bugs and/or feature requests in Bugzilla.