8tracks iPod Shuffle

I love 8tracks. And I love listening to my music while running or in the gym. Up to now I've used 8tracks’ fantastic iPhone app while out, and website and iPad app when at home or work.

Streaming music over my phones 3G is expensive, and strapping a phone to my arm is uncomfortable (and frankly looks silly.)

Also, Apple's matchbook sized iPod Shuffle, which holds 2GB of music, is a thing of beauty.

I wanted to marry the two and clearly I'm not the only one thinking along these lines: Check out Alecsandru Grigoriu's fan art product brochure.

This weekend I decided to write a simple 8tracks client in Python that saves the audio files locally for later upload to my Shuffle.

I’m using the 8track API and Python Requests library which vastly simplifies http comms. (I can’t believe I used to use httplib for this stuff…)

The client is it’s own user on 8tracks which happens to follow another user (me) and also just happens to play all the mixes in my iPod Shuffle collection. The client is well behaved: It downloads the tracks only as fast as if it were really playing them and reports the songs as played at the 30s mark, as per the API docs.

For anyone who’s interested I’ve got the code on BitBucket at https://bitbucket.org/dalehumby/8tracks-shuffle/. Feel free to contribute.

Take me to Funky Town

I don't know why, or who started it but ever since the all-nighters at Regus, Centuary City with 8 developers in a 10 square meter room, Lips Inc's 'Funky Town' has been our theme tune.

We've been threatening for the better part of two years to get our device to play that tune. That story is forever being deprioritised. But no more. Today we have an official command in our software stack called play_funky_town.



It was a quick dev spike to test the piezoelectric buzzer on our next revision of hardware where we changed from a self-driving, through-hole mounted buzzer to one that needs a 3 kHz square wave from the microcontroller. It also works at frequencies from 100 Hz to about 10 kHz, plenty for Funky Town!

And we can do other more serious stuff, like when we loose our device we can find it by triggering the play_funky_town command from the server and it bursts in to life, complete with a disco LED light sequence on the keypad.

The original awesomness that is Funky Town?

Scaleconf 2013

I gave a talk at Scaleconf about how Nomanini uses Continuous Deployment (and TDD and CI) across our full stack of hardware, embedded firmware and server backend code.





Quick plug: We're hiring. If you're interested in joining our team, let me know.

Almost 10 mechanical museums to visit with an autistic, boy-genius in Cape Town

Close friends of mine have a high-functioning autistic son of 11 who is crazy about anything mechanical. I'd say he was obsessed, but him mom says that obsessed is just a word that lazy people use to describe someone who's dedicated. William's particularly dedicated to Technic Lego and Mechano.

As a kid I remember going on plenty of outings with my parents to museums with a mechanical theme. Even 20 years later I could probably still describe their layout, how they worked and why. There was never any doubt in my mind that I wanted to study mechanical engineering and work on big machines.

Josephine Mill, Newlands

An operating water-wheel powered stone mill. The foul they produce is used to bake fresh bread. Loads of belts, pulleys, gears, shafts and moving parts to keep Will happy.

Steam train, Cape Town to Simons Town

After riding a steam train all I wanted to be 'when I grew up' was a train driver. Little did I know that the romantic age of steam had long passed. To me there is nothing more raw and mechanical than steam powered machines. Babbage had it right when he designed a steam powered computer.

Kleinplasie, Worcester

Just over an hours drive from Cape Town the Worcester Museum has an industrial agricultural display, including my favorite- a donkey powered water pump. (Bonus points: fly in to the Worcester airstrip, visit the museum, have some lunch and fly out.)

Mostert's Mill, de Waal drive

Another stone mill, this one powered by wind and sail. Much simpler than Josephine's mill but no less fascinating to watch. Open and woking on the third Saturday of each month (wind permitting.)

Water tunnel tours under Cape Town, Castle of Good Hope

Okay, so not really mechanical but something I wanted to do, anyway. Old water tunnels that used to carry water from the mountain to feed the Company Gardens. A new perspective of history of Cape Town.

SAS Sommerset, V&A Waterfront

Not currently open to the public, but open during school holidays for children's sleepovers. Once a coal burning ship it was converted to burning oil. Engine room is dingy, cramped, smells of oil and is jam-packed full of pipes and brass fittings- just as it should be.

Fort Wynyard, Green Point

Also closed to the public, but hopefully opening soon. (Best call the Simons Town Museum for details.) I remember being able to sit on and manoeuvre the anti-aircraft guns. My brother, cousins and I used to hand crank the ack-acks raining imagined destruction on Table Bay.

Athlone power station, Athlone

My uncle worked for Koeberg and managed to get his son and I a tour of Paarden Eiland coal power station shortly before it was demolished in the90's to make way for a container depot. The one at Athlone is likely almost identical inside. Wandering amongst the coal conveyors, boilers, turbines and generator halls was a surreal and fascinating experience. (I wonder if any coal power stations up-country are open for tours?)

Do you know about other mechanical themed outings for William? Let me know and we will take him.

American Electricians' Handbook, 1953

I was going through some old scans and images from a few years back and found this little gem.



I'd love to know if anyone has the original. In this day of Occupational Health and Safety it doesn't seem possible that this advice was considered safe.

[Quick check this excerpt isn't fake]

Our kanban story card

One of my primary inspirations for the switch to Kanban for product development was David Anderson's Kanban book. But in the Kindle edition the photographs and diagrams are so blurred that it's often difficult to figure out what he's describing. (To all Kindle authors: Please use vector graphics and high quality photographs. Please!)

Without tangible examples we had to discover the best way to lay-out our Kanban board and write-up story cards for ourselves and I think that's still the best way. But I hope our experience can inspire someone else.

The card layout

At top left is class of service. This story had a Fixed Delivery Date, FDD of Monday, 9 April. (As you can see we missed that date...) During planning we write the due date and can track our performance as the story moves down the Fixed Delivery Date swim lane.

The majority of the card it taken up by the story. We use style of "As a stakeholder, I want feature, so that goal." (A possibly better way to write stories is "In order to goal, stakeholder needs feature" because it puts the goal first, not last. I'll try find the reference.)

On the right hand side are the dates the story hit each of the stages in our delivery pipeline.

During the daily stand-up, for each day the story has been in progress it gets a dot. A green one if it's within the 5 day SLA, thereafter a red dot.

At the bottom left of the card we record the number of tasks written up during the stories planning session (5), tasks that we didn't think of during planning but had to do anyway (2), bugs and blockers (both 0.) I have been tracking these numbers and although I haven't formally analysed the data yet there is a definite trend between number of planned tasks and how long it takes a story to get through development. Basically, if during planning a story has more than about five tasks the dev team discusses splitting the story because it stands a good chance of missing our five day SLA. Retrospectively, we can determine how good our planning was based on the number of unplanned tasks a story had.

David Anderson suggests using sticky notes for stories and referencing them back to a bug tracking system. Most of our teams work is new features or bugs they file themselves. We haven't got to the complexity where we need software bug and feature tracking yet. So we wanted larger story cards, and use sticky notes for direct development task tracking. Our tasks take at most half a day for a pair of developers to complete, and the sticky notes get binned as soon as the story moves in to Demo or UAT. The developers mostly use them to record decisions made at the planning session for that story.

Curing the pox

I want to go back to the green and red dots for a minute. For the first month or so we didn't have a good way of visualising how long we had been working on a story. One could read the dates on the card but it was an effort to work out the number of days a story had been in progress taking in to account the weekends.

At that time we also had our WIP limits too high, and even then busted the limits more often than not. Delivery was slow and just about every story missed it's SLA. 

Lack of progress visualisation on the story level nearly caused us to go back to Scrum with it's simple, weekly burndown chart. 

But one of our developers came up with the idea of placing coloured dots on the cards, green when in SLA, red when out. He did this for each story that was in progress and called the dev team over to view his work. They were mortified- some cards had so many red dots that just about the entire front was covered. The wall was so full of red dots that it hurt to look at for more than a few seconds. Not only that, but our kanban wall is in a very public area of the office, so our red-dotted SLA-misses are very public and embarrassing. 

Over the next few days the team released the stories that had been languishing in UAT and Ready for Release, in turn reducing our WIP. 

This simple method helps answer the developers question, "What am I going to work on next?" They can go to the board and pick the story that's been in progress the longest and try and get it released. Picking the oldest story also encourages developers to pull work through the pipeline from right to left because the oldest stories will generally be toward the end of the pipeline.

Every time we increase visibility, whether of impediments, work in progress or time in development (as in this case) we see real productivity increases.

Back to blogging

The past year I have been working on a project, leading a development team building a low-cost, mobile point of sale terminal.

I wanted to restart my blog a while back but before we launched we were sworn to secrecy; and after launch have been incredibly busy improving our 'minimum viable product' that was initially more minimum than viable. (But six months of incremental improvements and learning from our market has lead to a better product.)

During all this time I kept a journal, aptly named 'What I would do differently next time.' It's a mix of my ramblings and rants and not really publishable like that. Besides, the Internet is permanent and I didn't want to publish anything I would regret later or be wrong about. But that's just naive: If it didn't upset someone the blog would be boring and not worth reading. And if I waited until I knew I was right then I would never press that Publish button.

Enter the infographic

(Expect to see loads more of these. Those who know we know how much I love charts.)

On the left of the curve are blog posts that are pure speculation and have no testable hypothesis, often written by those who spend more time writing about doing things than they actually spend doing anything.

On the far right are the gurus like Donald Reinertsen, who have spent years manicuring their ideas with the tools of science in order to separate the pure rubbish from the only sometimes wrong.

I hope to be somewhere to the right of centre more often than the left. But this is about documenting what I have learnt in a tech start-up. I want to be honest and not sugar-coat our mistakes. I want others to learn from them as much as we did. As with many things in life, better to ask forgiveness than permission.

What am I going to write about?
My passion is managing high-performance teams, putting just the right amount of process in place to give people the foundation to excel.

There are not enough tech entreprenures in South Africa who write about what they are doing or how they do it. And as far as I know, none are writing about developing hardware using iterative methods or putting embedded firmware in to continuous integration (CI.)

I really want to write about:

• Enabling a business by creating continuous delivery of features
• Iterating a product faster which leads to a competitive advantage
• The challenges and benefits of continuous integration of embedded system
• Deployment of new features in to highly distributed environments
• Scrum, Kanban, XP and other lean development methods
• Rapidly iterating hardware design
• Managing a mixed hardware/software product development project
• Raising capital
• Managing people
• And generally keeping a start-up functioning at its best

That said, my overarching theme is going to be about experimentation: I want to find methodologies that work for us rather than following word-for-word what everyone else does.