Our Blog

Hack Day Live

What a great day. The whole team working on different projects but of the same theme - the team work was fantastic (helped obviously by the numerous table football breaks and bountiful food!).

The projects that emerged from the day were:

• Fear the IOC - a bookmarklet to censor webpages of any term or image of which the IOC may take offence.
• Data Visualisations - taking some scraped data of past Olympic medals and visualising it with d3.js, a very cool Javascript library.
• Location-sensitive Chat Rooms - a service to allow users to gauge the buzz around a particular location, in this case Olympic venues.
• Json API for Olympic Data - Json API giving both historical medal data and 2012 schedule data in an easy to consume way.
• Web Visions - a node.js app taking streaming data from Twitter, 4Square and others and displaying location specific buzz.

And the winner was… the Json API, written by Alex with help from scrapers Paul and Toby. Awesome. Congratulations Alex.

We are now seeing how best to take these projects forward and make them demonstrable externally - we will keep you up to date!

For blow-by-blow of the day’s action, read on.

20:00 - So, after an super fun day of coding, pairing, sharing, scraping and eating, the team are ready to show and tell. We will eat and then display the results. But in short, a great day.

19:55 - Pizza here. Getting ready for demonstrations.

19:40 - Project 1. Code name Fear the IOC! Published on GitHub. Check out Mark’s handiwork at http://pebblecode.github.com/fear-the-IOC/

19:24 - Only 36 mins left of the hackday now until presentations, pizza and beer (well, we may have already had a couple of beers!). The demonstrations have started and the last few teams are frantically getting their day’s toil presentable. Screenshots and explanations of submissions coming soon.

15:57 - Just over 4 hours to go! Code getting written, committed and shared.

14:22 - More data scrapping from various sources. The geo-loc team making good progress, as is the social team. Data visualisation had hit a bump, but now back on track. IOC fear team already on the write up!

12:40 - Lunch has arrived.

12:30 - IOC fear bookmarklet preview on the Guardian website - ability to block out IOC trademark words or images:

12:20 - Massive tea round for Toby!

11:55 - Wow, raining outside!

11:35 - Looking at some very interesting data visualisations.

10:55 - Some images from the morning so far:

10:38 - Data feeds pouring in. Teams working well. Duke Ellington on the wireless! This is good fun!

09:30 - Break. Teams have been decided and discussions are flowing. The different teams are hitting the following topics:

• Social
• Data visualisation
• Locational / travel
• IOC fear!

Champagne and kudos for the people’s choice team.

09:00 - Ideas flowing.

08:32 - Team getting warmed up for the hard day ahead!

08:20 - Breakfast getting devoured. Ideas being discussed. Kick off is at 08:45. Excited.

07:49 - Office prepped. Food ready (courtesy of Al Desco). Early birds arriving.

On Technical Debt

Listening to a recent Ruby Rogues podcast the topic of Technical Debt came up that really rang true for many of our projects and clients.

Making Agile Decisions

The discussion notes that the point of Agile is to get a product to market as quickly as possible to prove the business value or otherwise of an idea. In the course of an Agile project decisions are made to facilitate this. It might be a quick and dirty feature, not having full test coverage or hacking together a quick library to support a feature going into production.

The point is that this is completely correct - you want to get a product out there and prove a business idea. But there should be a realisation that if you are developing and supporting software long term there will be a point at which these decisions will have to be paid back.

Accruing Technical Debt

In almost all of our projects at pebble we have examples of this and this represents normal, Agile software development. But discussing Technical Debt with a client is a good way to let the client know in simple, understandable terminology of the impact of a decision. By discussing it this way we can be clear that at some point the debt from a decision may have to be repaid. By the same token there will be scenarios where taking on more technical debt is the right choice.

Repaying Technical Debt

In the context of our work depending on how much debt a project / client wants to take on there is a good case for us scheduling a debt repayment sprint in our Agile projects once and a while. The business value is that it will support future features, stability and decrease long term development costs. There will also be cases where accruing debt is completely acceptable. It should be assessed on a case by case basis.

Clear Terminology For Clients

I like this terminology in terms of how we can work through business level decisions with clients and make informed choices for the direction of Agile software development.

We have been prone to sharp intakes of breath at feature requests in the past and have explicitly stated this is something we hate noticing ourselves doing. As an Agile house we should never being saying no to features but positioning them within a business context and helping clients to make informed decisions. Terminology like Technical Debt lets us do that and communicate clearly and openly with the client.

The discussion comes highly recommended if you are involved with Agile software development.