A couple of years ago, one of our technical architects at the Hut Group ran a few code dojos to give the team experience of TDD and Pair Programming. The team has grown massively in the meantime, so I thought it would be a good opportunity to try it again.

To quote from codingdojo.org a dojo is:

…a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in DeliberatePractice in order to improve their skills.

So, I booked the boardroom, setup an Intellij project on my MacBook and waited for the developers to arrive. In the end about 10 people came, with a range of development experience from less than a year, to more than we’d care to admit to.

The exercise I chose for the group was to implement the “fizz buzz” game. Basically for a given natural number greater zero return

• “fizz” if the number is divisible by 3
• “buzz” if the number is divisible by 5
• “fizzbuzz” if the number is divisible by both 3 and 5
• otherwise return the number

The first comedy moment was when we went round the table and tried to play “fizz buzz”. You’d have thought a group of highly skilled IT professionals would be able to do simple mental arithmetic, but this is apparently not the case…

The problem itself isn’t all that complicated, a decent developer could write the code in 5 minutes, but the point of the exercise isn’t really the end solution. More important is how you get to it. A pair of developers worked at the laptop. The driver types, focuses on tactics and writing clean code that compiles and runs. The navigator focuses on strategy. How the code fits into the overall design, which tests will drive the code forward, and which refactorings will improve the entire codebase.

We also wanted to build the solution using Test Driven Development. You write a test that fails, write some code to make it pass and then refactor. With a problem this simple it is quite difficult to force yourself to follow these steps.

We started with the simplest case we could think of, i.e. if you pass in 1, you get 1 back and built from there. We managed 7 iterations in the time we had available and got to a reasonable solution.

Going through the exercise prompted a lot of interesting debate. We talked about how you identify test cases, different ways of implementing the algorithm and even got into some OO design. I think the group found the exercise useful, I guess the proof will be when I see how many people come to the second code dojo.

There was one thing that I didn’t think worked too well. The navigator didn’t really get to contribute as the entire group chipped in ideas so effectively we had 10 navigators, but I’m not sure if this wasn’t a good thing.

Next time I may try using cyber-dojo which would allow pairs to work at the same time. It is a pretty neat site where you select a exercise and can code it online in a huge number of languages. One thing it does prove is that Java is a bit of a nightmare without an IDE, Ruby is the future!

I think it looks much better now and it was pretty simple to implement.

Moving forward to the present day. I work for one of the UK’s largest online retailers and not liking GUIs is a bit of a disadvantage. I can knock up a webpage pretty quickly and can even do css to a degree, but I’m far from great and not in the same league as our front-end dev team.

I’ve been listening in on a few conversations and Bootstrap from Twitter came up. Bootstrap aims to provide Simple and flexible HTML, CSS, and Javascript for popular user interface components and interactions. I have to admit it seems to do it pretty darn well. I’ve been having a play with it this evening and have managed to knock up a couple of decent (in my opinion) looking screens pretty easily. I’ve got a functional nav-bar, some drop down menus and a reasonable looking form. All the javascript you need comes with it, the css is easy to apply to the html and there are some nice looking icons with it as well. All in all it’s been a pretty painless experience.

It might be time to buy some flip-flops, get a couple of shirts from Threadless and see if I can join the design team… (although my complete lack of talent will probably count against me).

If you interested, Bootstrap can be found here.

An example of my efforts is here.

I have it set up to so that “ssh server username” will connect to server as username. If you don’t put it a username it will default to “default”.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

on alfred_script(q)
	set tmp to splitString(item 1 of q, " ")
 
	set server to item 1 of tmp
 
	if length of tmp is 2 then set login to item 2 of tmp
	if length of tmp is 1 then set login to "default"
 
	set command to "ssh " & server & " -l " & login
 
	tell application "Terminal"
		do script command
	end tell
end alfred_script
 
to splitString(aString, delimiter)
	set retVal to {}
	set prevDelimiter to AppleScript's text item delimiters
	set AppleScript's text item delimiters to {delimiter}
	set retVal to every text item of aString
	set AppleScript's text item delimiters to prevDelimiter
	return retVal
end splitString

Phil (see comments) wrote a version that can handle ports as well. I’ve changed it slightly as something appears to have changed within Alfred which was causing it to ignore the username passed in.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

on alfred_script(q)
	set tmp to splitString(item 1 of q, " ")
 
	set server to item 1 of tmp
 
	(* Split at colon delimiter *)
	set server to splitString(server, ":")
 
	(* Does it contain a port? If not just roll with it. *)
	if length of server is 2 then
		set serverport to item 2 of server
		set serverip to item 1 of server
		set server to serverip & " -p " & serverport
	end if
 
	if length of tmp is 2 then set login to item 2 of tmp
	if length of tmp is 1 then set login to "default"
 
	set command to "ssh " & server & " -l " & login
 
	tell application "Terminal"
		do script command
	end tell
end alfred_script

I joined the Hut Group because I was getting bored at Atos Origin. I was working on a project for a large government department and although some of the things we were doing were interesting, it felt like I was destined to work on the project for the long term. A former colleague, Tim, was at the Hut at Head of IT and he asked me to come over and help him sort things out. I turned down the initial offer, but eventually decided to take the opportunity. The main reasons were that I knew Tim, and I wanted to try my hand at web development.

I joined the Hut Group as a Senior Developer and worked on mostly back-end projects. I integrated with a flowers supplier (not a great success), wrote a backup payment system and made lots and lots of changes to our back office system. I also made a good few changes to the website, including replacing the password reminder system.

At Atos Origin I had a number of roles as a configuration manager and it seemed natural that I would attempt to sort things out in this area at the Hut as well. We use subversion and I used to police the developers to make sure that they were using it correctly.

During all of this the development team grew pretty quickly. We I started we had 10 people in the IT department, including the TA, Head of IT and support team. A new CTO joined us, and we went on a recruitment drive that hasn’t really stopped.

As the team got bigger I moved into a TA role so that we could provide some technical leadership to the developers. I worked alongside the Chief Technical Architect (James) and helped get some pretty major changes to the platform in. I also spent a lot of time improving our monitoring so we could tell when the platform was having problems.

About 2 years ago Tim decided to take a new role, so I became the Development Manager and later the Head of Development. Our current CIO (Gareth) joined shortly afterwards and under his leadership we started to introduce agile development.

Our original process for getting work into the team was for a business stakeholder to fill in a work request form which one of the team would look at and estimate the effort involve. We would group a few of these together and form a project to be delivered. This was the theory in any case. What actually happened is that the work request forms sat in one of several large folders on my desk and pretty much got ignored. What the team actually worked on was whatever a few senior people in the group decided was important. The process wasn’t very transparent and we had a tendency to start work and not finish it. Things were not great, and nobody was satisfied with performance of the team.

The first thing we did to more towards an agile methodology was to get control of the work coming in to the team. I went round all the business to talk to them about what work they wanted to be delivered over the next twelve months. These were all written on index cards and James, Gareth and I gave t-shirt size estimates to them all (S, M, L, XL) and fitted them on to a rough plan. We moved away from 15 developers meaning 15 projects on the go, and organised everybody into small teams. We recruited a number of tech leads to lead the teams and they worked with the teams to get the agile practices we want embedded into the team.

Things began to improve pretty quickly, but it became clear that the Tech Leads were struggling to balance the management side of their role with the technical leadership of the team. We already had a business analyst working with us, and he moved into a project management role and we recruited two more PMs. The PMs work closely with the business to understand their requirements and act as Scrum Master for the project teams. They basically make sure that the developers can concentrate on developing and they remove any impediments that stop them.

I think the best change we made was decreasing the number of teams. We ended up with 7 teams with a couple of people in them, and this caused a few problems. There was a limit to who people could pair with, and limited the amount of work a team could do. If anybody was on holiday, work basically stopped until they came back. Worst of all it was difficult to get the team to self organise and engender any sort of team spirit. We cut the number of teams down to 3, each with 6 or 7 people in them. We’ve kept these pretty constant for about six months and they are now very productive. The teams organise themselves (to a certain extent), and we’ve got a good spirit in all of them.

The final change we’ve made is to create a “Rapid Response” team. This team handles all the day-to-day requests that come in to the development team. These range from fixing defects, to delivering new pieces of functionality. We aim for a piece of work delivered by the team in 3 days or less. We manage the work of the team using a kanban board, with the business prioritising all the outstanding requests twice a week. The prioritisation meetings take about 15 minutes and we have some really good discussions about what is important to the business. We’re delivering on average 5 tasks a week and the business like it as they have very clear visibility of what the team is working on now and next. The best thing is that they can see things being delivered.

So what will the future hold? I personally think we will move away from delivering “projects” to delivering features. These will be smaller pieces of work that we can deliver constantly. There will always be projects to deliver, but a lot of what we do is already feature based and a lot of the time we use scrum and sprints to mark time.

The biggest change on the horizon is that we are recruiting a number of test engineers. These will work with the development teams to promote best practice and help us automate our testing process. We’ve done some work in this area, but we have a long way to go. I’m quite excited about some of the things we can do with tools like Cucumber to aid automated acceptance testing.

What about me? It looks like I am going to get more involved on the technology side of things. We have a number of interesting challenges coming up to make the platform scale to support the continued growth of the business. The good thing about the Hut is we can react quickly to new opportunities and making the IT do this is good fun.

Anyway, the “BAU” name is pretty dull and undersells both the value of the work that the team does and it’s complexity so we’ve decided to rename them the Rapid Response Team. I have even done a logo!

Apologies in advance to our entire Design team and anybody with a modicum of taste for the abomination that am I about to release on the world. I did maths at Uni and I absolutely hated art having realised at an early age that I completely suck at it.

Anyway…

I’m going to quote from the last paragraph:

To be honest, if someone wrote to me with a nice covering letter and spoke about open source projects that he or she liked, pointed me at a Twitter feed where they were intelligently engaged in the problem domain, and sent me some code that they’d written, they’d be more or less hired at this point. No one wants to see a list of technologies with some random skill level or years experience.

If you’re interested in joining the Hut Group, check out our careers page and get in touch. I can be reached directly via my twitter account @typingincolor.