My Favourite Project

You know what, blogs like this one got me thinking. Some people work on a lot of projects over their lifetime, but what makes a project really stand out as a great experience?

If you haven’t read Ben’s article, I suggest you do because it starts to discuss ways in which projects can become unexpectantly enjoyable.

Like a lot of people in IT (or technology or digital or whatever it’s called these days), I’ve had my fair share of great projects and down-right average ones.

Some of the standout drop-kick-of-a-project projects tended to be very large, extremely ambitious goals, loads of external consultants, big dollars and generally sponsored by people who couldn’t dedicate enough time. But this post is not about these kinds of projects.

I wanted to work out a list of things which made some projects successful for me (your experiences may differ) and focus specifically on one project.

Maybe it’s not absolutely my favourite project of all time, but it’s easy to forget earlier projects as time progresses.

I started on this project, almost organically, in a large government-funded media organisation a few years ago. Some of you may have heard of this organisation. The “project” didn’t exactly come out of a standard capex-funded procedure from what I could work out: it was a bit of a nice idea, sketched out on some paper, with some help from the solution architects at Amazon Web Services.

The project (or initiative) was to cut costs of transcoding (aka converting video from one format to another) by a factor of 40. The project would take around 6 months to deliver and could pay for itself after a further 6 months. Not a bad return on investment!

The project team consisted of a lead who had a passion for video streaming, 3 backend developers, a support specialist for integrating with an on-demand video service, a media operations person to assist in testing and myself: someone who doesn’t mind drawing a few boxes on a page. (I actually did some of the coding but generally spent most of my time discussing solution design and crafting transcoding profiles and chains of filters for FFmpeg).

The way the team came together appeared really organic to me. It was almost like a creeper project, slowly drawing people into the vortex, without complete endorsement from some of the greater powers.

Some key roles were absent from this project: we didn’t have a delivery lead or project manager, however we organised our work into sprints and had standups and all the normaly agiley sorts of things. The lead of the project really drove the solution and helped with the vendor (AWS) and also managed internal stakeholders, but never really proclaimed themself as a ‘scrummaster’ or similar.

Talking about location for a moment: we had the (arguably) worst place to call ‘home’ on the office floor: bang in the middle, surrounded (mostly) by walls, zero natural light, on a pathway to the kitchen and bathroom. It was rather affectionately known as ’the cave’ and was known for having the worst aircon circulation (it got really hot on Friday afternoons during drinks). But hey! People wanted to gather there for drinks. There was a great social vibe. Pretty odd for the worst part of the floor!

We made the best of what we had. We played fridge scrabble, we played silly YouTube videos of general ‘office’ clatter to sound busy and we generally made fun where we could. We served tea from a communal pot and replenished it with Melbourne Breakfast tea whenever we ran out.

We tried to get infrastructure costs as low as possible, but backed off when things got a bit silly. We started out looking at using DynamoDB because it was so tempting at 50 cents a month, then we hit some throughput limits and decided we could pay a few more dollars for a proper RDS database. There were many optimisations we could’ve made along the way, but often it’s just not worth the hours/days/etc it takes to implement and test for a small saving.

We wrote a lot of internal blogs. We made it our mission to make them as amusing as possible. So I made it my mission to discover many new Confluence security bugs, of which Atlassian supplied swag in response to each new security bug found. We worked out how to embed video, a tetris game, made snow appear on Confluence pages, made background sounds play immediately when reading the blog and automatically forced people to ’like’ blog posts when they visited. Shenanigans are important!

I learnt some new skills during the project as well, including how to configure FFmpeg (it’s a tricky beast to tame), watermarking, audio processing and what it meant to ’extract captions from a GXF format video file encoded with OP47 aka RDD-08 by SMPTE). Actually just on that, I started to add a new plugin for ffmpeg so it could understand OP47, which I didn’t quite finish but it was extremely fast to run and satisfying writing the solution in C.

We launched the project, which saved a huge chunk of cash and thought it would be good to tour around and talk about it. So we did. We did meetups, YOW presentations and internal showcases. It was great to talk about what we had done and how the team got there in the end.

It was great to see the leadership team be so supportive of the effort once we had delivered because it was such a success for the organisation.

We had to come up with a name for the system, one which could replace the boring codename that we used during the project (DNVW). After a couple of hours in front of the whiteboard, we settled on “Metro”. It was simple and can be considered a shortened version of MEdia TRanscoder, but with a decent dose of Aussie twang thrown in for good measure.

All things come to an end of course, so the project team packed up, handed over what they could to existing teams, and promptly moved on to other initiatives.

You can read more about the Metro project here:

• https://developers.digital.abc.net.au/2016/02/15/introducing-the-abcs-new-video-transcoding-service-metro/
• https://developers.digital.abc.net.au/2016/03/22/tech-talk-on-metro-future-dates-and-talk-slides/

Comments (0)