home

Boost Blog

Archive for the ‘Development’ Category

November 2nd, 2011

Pair programming: When and why

Posted by Federico on November 2nd, 2011

Here at Boost we’ve been pair programming for a while, and seeing benefits in the form of cohesion and knowledge sharing, as well as the quality of code we produce when working in pairs. As part of the adoption of this practice I set out to research how pair programming has been working for other teams and how it can be used to improve the team dynamics.

For those that are new to the concept of pair programming: at its core, it’s when two developers sit in front of the same computer and develop code together.  One programmer acts as a driver and the other as the navigator. The driver controls the keyboard and mouse and is concerned with the concrete tasks of coding, while the navigator reviews the code and thinks about bigger picture issues.

It’s not for every team

As Obie Fernandez explains in his article “10 reasons pair programming is not for the masses”, in order for pairing to work the team has to consist of developers who are committed to their work, and who are sociable and able to interact with other team members. Otherwise problems will quickly arise when you are working in such close proximity with other team members.

Why it’s great

Few or no bugs: The first thing you will notice when pair programming is how few bugs are left in code produced by the pair. Pair programming is like a constant code review process, which is why typos or small details that a single programmer normally wouldn’t notice gets spotted almost instantly by the navigator, eliminating hours of debugging later on.

Code quality: The general quality of the code is also greatly increased. This is because while the driver is implementing the logic, the navigator is free both to spot errors and to think about the big picture and how it relates to the rest of the code.

Programmer productivity: When working alone it is very easy to get distracted by email, twitter, Facebook, and all the things going on within the office. When working in pairs, if you were to do any of those things it would waste the other person’s time, so pair programming is a constant reminder to focus on the work.

Knowledge transfer: In an environment where developers work alone, it can be hard to share knowledge because there often isn’t a time or place to do it. Pair programming involves constant discussion and flow of ideas on how to resolve a problem, and normally a pair can come up with many different solutions to a single problem. It’s also great in situations where you want to introduce a new team member, to get them up to speed very quickly with the development practices, coding style, git workflow and other practices the developers might use.

How to do it

When: Although some of the development companies promoting pair programming suggest using it 100% of the time, in my own experience the intense focus and concentration that happens with pair programming can be draining over a full day. I suggest you pick the tasks that will benefit from having a pair work on them, rather than applying pair programming to every task.

Workstation setup: We have been using just one display, keyboard and mouse with great success but I would definitely like to experiment with two keyboards and see how the interaction between developers works out.

Rotating pairs: One important aspect is to let developers constantly change pairs, on a daily or weekly basis. This has several benefits: it helps develop a bond between the team members; the team as a whole takes ownership of the code instead of individuals; and knowledge sharing is increased by working with developers with different levels of experience and backgrounds.

Resources

  • Obie Fernandez – 10 Reasons Pair Programming Is Not For the Masses
  • WikiHow – How to Pair Program
  • Computer.org – How Pair Programming  Really Work
  • Ian Burgess – Pair Programming- Software Development Learning Steps
 
Tags: agile, agile development, pair programming, professional learning, Quality assurance, research
Posted in: Agile, Development
No Comments
 
August 15th, 2011

Jeff Sutherland on the History and Structure of Scrum

Posted by Jacob on August 15th, 2011

As you might have noticed lately, we’ve been talking a lot about Scrum – we’ve done a great post on Learning Scrum in 10 Minutes, and for those of you in Wellington, we’re even running free Scrum workshops.

All of this is really useful, really interesting information, and we hope that you are all getting value from it. From these posts, and through our Twitter stream one of the questions we’ve been getting most frequently is about the history of Scrum – where did it come from and why did it turn out the way it did?

To answer this question we’ve got a video straight from the source with one of the founders of Scrum, Jeff Sutherland.

Check out the video below to learn about the history and reasoning behind Scrum.

Where did Scrum come from?

The logic behind Scrum as a development methodology is really very interesting, and Jeff Sutherland does a great job of explaining it. There are a few key points I find particularly interesting, and that are reflected in Scrum processes as we see them today:

    Why other systems don’t work:

  • Specialised silos of activity leads to slower communication and add lengths to the development process – this makes sense as there is not enough communication between people with different roles so it makes it hard to achieve the goals or development milestones that they have committed to

How they developed Scrum processes

    The roles of Scrum

  • To simplify the process they created teams with just two roles – a team and a team leader (aka The Scrum Master)
  • They found that the needed someone who truly understood the requirements of a project as well as representing the users, and so they came up with the role of Product Owner. This way every development cycle would add value for users and the business, and the team would have someone on hand who understood the requirements of each piece of functionality and could explain the reasoning each part of the project

    The meetings of Scrum

  • Experience shows (and anyone who works in a large organisation can testify) that too many meetings slow down the development process; in order to speed up the process, the needed to reduce the number of meetings to a minimum amount
  • They found development should be done in short cycles of 2 to 4 weeks (aka sprints) – essentially so there is good communication, and each development cycle can be well estimated
  • You need a meeting at the beginning of a sprint to define what you are going to pull from the product backlog (as managed by the Product Owner), how you are going to implement and track each item from the backlog
  • Research from Bell Labs showed that teams were driven by daily meetings, but they wanted it to be a very short meeting of no more than 15 minutes, so all members of the team knew what was going on, what they were going to achieve and how they could help other team members
  • At the end of a sprint, you would demo real, working software to get feedback from the product owners and stakeholders of the project, so you know what’s working well and what’s not – that feedback cycle (aka a Retrospective) is what helps teams to improve and help development go faster

    Reporting in Scrum

  • They needed to do a rethink of how reporting would occur in software development as the traditional method of using Gantt charts simply didn’t work as too many changes occur. They came up with the concept of a Burndown Chart so you could see a glance how fast the team was going, how much work was remaining and how much time was left to do it
  • They left the Burndown Chart up on the wall as a method of self reporting. Everyone could see the state of the Scrum at any time, and immediately know how much work was left to do.
  • They used a visual workspace (again, up on a wall) so you could see what needed to be done, what work was in progress, and what was done and tested at any moment in time

Scrum in a nutshell

So that’s more or less how Scrum came about – quite an interesting story really. Jeff Sutherland is evidently a very interesting character, and the thought that has gone into making Scrum as efficient is really very apparent.

Does this match up with your own experiences of Scrum? How does Scrum work for you? Did you enjoy your history lesson? Be sure to let us know in the comments below.

Want to learn more about Scrum? Be sure to sign up for our RSS feed, or follow us on Twitter and Facebook for more great information. Thanks for dropping by!

 
Tags:
Posted in: Agile, Business, Development
No Comments
 
February 9th, 2011

Jelly at Boost: Friday co-working for free

Posted by Nathan on February 9th, 2011

Jelly at Boost is casual co-working in Wellington. Every Friday we open our space for 10 people to work, drink our coffee and steal our wifi for free. We are a small part of a large international movement that started in a Brooklyn apartment with some contractors sharing their lounge. There are now Jellies in over a hundred cities.

Why are we Jellying?
We want to give back to the design and development community. Wellington is a great place to be creative and we want to do our part in making it even better. We want to provide a low key, easy going space where people can get work done.

We’re not on an idealogical mission to join all humanity in loving harmony; though if it did happen, we’d be surprised, very surprised, but we wouldn’t freak out :-).

We’ve had some great feedback from the first Jelly last Friday, and are looking forward to this week’s Jelly. Space is limited so if you are keen DM us on Twitter (or drop us an email) with your name and what you will be working on (broadly speaking) and we will save you a place.

Hope to see you soon.

 
Tags: co-working, jelly at boost, wellington
Posted in: Design, Development, Magic & Delight
No Comments
 
July 16th, 2010

Friday links: design, development, usability and more

Posted by courtney on July 16th, 2010

This is the first entry in a semi-regular series sharing things that we’ve been looking at and reading recently …

Sarah (one of our project managers)

  • Broadband becomes a legal right in Finland
  • Guggenheim collaborates with YouTube and invites video submissions

Sue (one of our designers, recently returned from a break in the sunny northern hemisphere)

  • Eye-candy and inspiration on www.citid.net
  • Great experimental fonts (also: free!)
  • Lighten up your winter blues: heaps of colour and shapes on Coolhunter

Alastair (one of our developers)

  • Firefox 4 introduces more HTML 5 and CSS functionality. One step further towards the death of Flash? Still in beta so one for the developers.
  • Excellent! Wayne and Garth spotted in the UK. Party on!

Rachel (our office manager)

  • Artist creates masterpiece on an iPad
  • World Cup 2010 statistics: all the key data for each team, from the Guardian

(Rachel notes that she’s not as much of a sports fiend as the above link might suggest, and also recommends data/infographic blog Cool Infographics)

Jake (who looks after our usability testing tool IntuitionHQ)

  • David Gillis on Fusing Content Strategy with Design, in UX Magazine
  • The Real Life Social Network, slides from a presentation by Paul Adams, Senior User Experience Researcher at Google
  • Gnarcade – Video Game Invasion: for video game fans, and geeks in general

Courtney (that’s me – project manager)

  • Aaron Straup Cope’s magical slippy map showing the world as revealed by geo-tagged photos on Flickr
  • Significant Objects, an investigation of art and the market through short stories and eBay
  • Swallows and Amazons, the current exhibition at Robert Heald Gallery, which is close to our office – on show until 31 July.
 
Tags: inspiration, research
Posted in: Cool tools, Design, Development, Random thoughts, Usabilty
No Comments
 
July 5th, 2010

Working with Git

Posted by jeremy on July 5th, 2010

During a brief slow period on a Friday afternoon I started pondering how much work I actually do, and if it was even useful knowing. Obviously all our code is stored in a version control system (git), so in a way all of the data for finding out the quantity of work is readily available. A little investigation and I found that it’s quite easy to pull a list of commits from git showing total lines added and deleted per file:

git log --oneline --numstat

I’ve committed a lot of code that I didn’t write, such as plugins, the Rails framework etc. So a quick and dirty ruby script later I could get a list of all unique files in all repositories that I’ve committed to. It was pretty easy to go through the list and create an exclusion list. I then broke out Ruport to aggregate everything by extension. That gave me the following table:

I’ve cleaned this up a little and collapsed some alternative extensions down.

Commits per week

Just over 110,000 lines added and 50,000 deleted, of which about 100,000 are to Ruby files. Now I’m not claiming to have written all those lines myself, any part of any line changed counts towards the total. All this does is illustrate the general balance of work that I do. There have been two lines added for every line deleted. This year has seen a lot of refactoring work, so it’ll be interesting to run the same exercise next year and see if the results are similar (of course git holds historical data, but we only started using it about 18 months ago, and previously had everything stored in subversion).

It’s interesting to see that the proportion of additons to deletions is much higher in view (rhtml/haml) files than in ruby code. This could point to the way things look being changed much more than the way things work.

Now if only there was a way to measure the quality of work. (Actually there are tools; metric_fu is a good starting point and we use it a lot at Boost. However, that’s going a little too far for this post).

Another interesting bit of data I extracted from git is the number of commits I’ve done per week over the last 52 weeks.

I’ve posted my script as a github gist. You  can run it by modifying the @repositories array with a list of git repositories, @author with your email address and @excludes with a list of regular expressions for excluding files. Run the script as ruby gitcount.rb. If it is run with the argument “files” then it will list individual files, making it easier to build the exclude list.

 
Tags: git, ruby
Posted in: Development, Random thoughts
No Comments
 
February 1st, 2010

DrupalSouth Presentation

Posted by paul on February 1st, 2010

DrupalSouth, an annual gathering of Drupal people from around New Zealand, happened over the long weekend here in Wellington.

The venue was Mac’s Brewery; a great location on the Wellington waterfront, a good venue for a conference of this size and of course geeks love good beer, it’s a fact.

Alastair (a fellow Boost developer) and I presented a talk on beginning Drupal module development at one of two Sunday morning red-eye sessions. Our presentation focused on getting people started with Drupal module development. The intention was to give simple examples of how you can tap into Drupal hooks and other elements of the API, such as the Form API.

Pitching a technical talk to beginners is always difficult depending on the background of the audience, hopefully it’s simple enough to understand while giving enough information for those who are raring to go.

The presentation slides and our sample code are available to download.

  • Presentation slides
  • Sample code

Any feedback will be appreciated, please feel free to comment.

 
Tags:
Posted in: Development, Drupal
6 Comments
 
January 26th, 2010

Scrum and Kanban – a developer’s perspective

Posted by jeremy on January 26th, 2010

We’ve been using Kanban for a few weeks now on some projects, taking over from Scrum where appropriate. We’ve used the Kanban process for projects in ongoing maintenance and for those that seem more like a list of tasks to be performed (Drupal CMS integration). more »

 
Tags:
Posted in: Agile, Development
7 Comments
 
January 26th, 2010

Drupal linked themes

Posted by jeremy on January 26th, 2010

We’ve released our first public Drupal module – linkedtheme. This modules gives you the ability to link themes together so that they share their block configuration, great for subthemes. more »

 
Tags: Drupal
Posted in: Development
No Comments
 
December 3rd, 2009

Scrum and Kanban – less is more

Posted by Nathan on December 3rd, 2009

Here at Boost we are always endeavouring to improve our processes and ultimately our outputs. The ‘cycle of continuous improvement’, if you will. This means we actively looking for new ideas to test and where appropriate integrate into our day.

Recently we have been researching the agile process Kanban and how it might integrate with our Scrum processes. Kanban is a less prescriptive agile methodology than Scrum. It concentrates on moving items through the pipeline from formulation to completion. It shares many ideas with Scrum and often Kanban teams adopt Scrum artifacts such as daily standups.

What is Kanban

Kanban is an agile methodology that shares much in common with Scrum, but it also has a number of key differences. For example, where scrum uses sprints to limit work in progress, Kanban limits work in progress by workflow state.

more »

 
Tags: Development
Posted in: Agile, Development
No Comments
 
October 27th, 2009

How the west was clustered

Posted by jeremy on October 27th, 2009
Screen shot 2009-10-27 at 9.20.25 AM

A cluster on IntuitionHQ

Our new product, IntuitionHQ, shows clusters of clicks on an image. To generate these clusters we made use of a gem called Hierclust. The great thing about this gem is it’s simplicity – just input the points and a minimum cluster separation, and out come the clusters.

The problem with Hierclust was the performance. With fewer than 100 points to cluster Hierclust was running too slow to do it dynamically. This was no problem, we moved the clustering program into a cronjob and stored the data in a marshalled file.

However, in testing we found that Hierclust was still too slow. Once we had over 200 points being clustered it started taking minutes to process – an unsustainable amount of time for the data we expected. The graph below shows the timings, which I believe is O(n3). We had to disable cluster processing while looking at the problem due to issues it was causing on the server.

Screen shot 2009-10-27 at 10.14.36 AM

Graph of points v time taken

more »

 
Tags: rails, ruby
Posted in: Development
1 Comment
 
« Older Entries
  • Categories

    • Agile (23)
    • Agile Coaching (1)
    • Business (3)
    • Cool tools (5)
    • Design (7)
    • Development (17)
    • Drupal (1)
    • e-Learning (70)
    • Magic & Delight (6)
    • Publishing (3)
    • Random thoughts (7)
    • Ruby on Rails (9)
    • Scrum (9)
    • Social media (9)
    • Usabilty (4)
    • Writing (1)
  • Archives

    • January 2012 (3)
    • November 2011 (4)
    • August 2011 (5)
    • July 2011 (1)
    • June 2011 (2)
    • May 2011 (4)
    • April 2011 (1)
    • March 2011 (1)
    • February 2011 (1)
    • November 2010 (1)
    • October 2010 (1)
    • September 2010 (3)
    • August 2010 (4)
    • July 2010 (6)
    • June 2010 (2)
    • April 2010 (1)
    • March 2010 (1)
    • February 2010 (1)
    • January 2010 (3)
    • December 2009 (1)
    • November 2009 (1)
    • October 2009 (4)
    • September 2009 (2)
    • August 2009 (3)
    • July 2009 (6)
    • June 2009 (3)
    • May 2009 (1)
    • April 2009 (6)
    • March 2009 (6)
    • February 2009 (11)
    • December 2008 (4)
    • November 2008 (6)
    • October 2008 (12)
    • September 2008 (7)
    • August 2008 (7)
    • July 2008 (4)
  • Boost Loves Design

    • I love Typography
    • IntuitionHQ | easy website usability
    • OMG It even has a watermark
  • Follow me on Twitter
© Boost Limited.
All rights reserved.
CONTACT US
info@boost.co.nz
tel. (04) 939 0062
fax. (04) 939 0063

Level 6, 175 Victoria Street
PO Box 11504, Wellington
New Zealand