Media View Toggle Buttons

By stevel stevel

Picture 3One of the things implemented in Purple Rain (the new Feather in Songbird 1.4) was direct toggle buttons to select the current Media View.  However, we only implemented them for the built in List View & Filter View buttons.  Third party Media Views were still only listed in the arrow-drop-down menu button next to them.  I’m happy to say that we’ve landed bug 18538 on trunk yesterday which will allow Media View developers to create and define icons to represent their Media View.  They will be automatically inserted into the row of buttons to allow users to more easily switch to the available views.

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:

mpIcon

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!

Updated locations for Concerts

By stevel stevel

Picture 2

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.

Make long term planning possible in an Agile environment

By Georges Auberger Georges Auberger

Agile development methods are well suited to plan and execute near term release cycle. For instance, the tools we developed and processes we’ve adopted help us plan and steer a release to completion with a good level of accuracy and repeatability. However, there are instances when the time horizon needs to be further out than the current cycle. The need to create a budget, synchronize a roadmap with a partner or determine future hiring needs, make it necessary to have an effective mechanism for long term planning.

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:

Fugazi Genesis Hendrix Isan Jackson 5 Kanye Led Zeppelin
Planned Features [pts] 198 300 145 100 160 153 86
Actual Completed [pts] 696 946 527 419 432 694 303
Actual Completed Features [pts] 290 304 183 151 214 284 145
Planned/Completed Features ratio 146% 101% 126% 151% 134% 186% 169%
Actual duration [days] 39 55 56 50 50 55 30

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.”

Dashboard for Agile project tracking

By Georges Auberger Georges Auberger

This is a following post to the series on Agile development at Songbird. As covered previously, we’ve created in-house tools to help with the planning and tracking of our release trains. The tool works off of Bugzilla and extracts meaningful information for project tracking. As it was originally meant to periodically generate an email status, it became apparent that it was too static for daily project tracking needs.

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.

1.4 Updates Flying the Coop

By Preed Preed

As promised, we’ve just started pushing updates from 1.2.0 to the new 1.4.3 release!

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.)