Technology Blog

Last week was the annual open day for the 2^nd year group project at the Computer Science School at the University of Nottingham. The open day forms a significant part of the group project module as it calls for the groups to present the software they’ve built over the last few months at a mock trade show, complete with posters, demonstrations, branded t-shirts and plenty of attention grabbing cake or sweets.

7digital were represented at the open day by Leon Hewitt and Paul Shannon, which is 7digital’s second year in attendance,  except this time we were judging a slightly different prize. After previous prize sponsors decided to sponsor elsewhere we were asked, along with Esendex (a Nottingham based technology company and the UK’s leading specialist business SMS provider) to potentially provide some goodies. As we’re quite friendly with Esendex and share a similar approach and passion for software quality we thought the best solution was to pair up and jointly sponsor a prize looking directly at the quality of the software produced by the students.

The 7digital and Esendex Prize for Software Quality

We defined criteria based on the principles and practices that we use to make well crafted software. As this is the first time the students have to form a team to complete a project we didn’t just focus on the actual code either, looking at the following areas:

• Knowledge Sharing
• Team Organisation
• Code Quality
• Code Architecture
• Testing

Knowing that in previous years teams generally had 1 coder, 1 UI coder, 1 documenter and someone else to manage all the work, we’d hoped this emphasis on sharing might encourage better collaboration.

More details about the participants and prizes on the group project home page. Our full criteria for the prize is available too.

Our Findings

We had access to the reports and source code repositories of all 26 teams, splitting the work between the two judging companies to arrive at a short list of 4. We didn’t expect perfectly clean code with great test coverage and well prioritised work flows but we did see flourishes of quality software in various teams.

Overall the quality of the software was an improvement on previous years, reflecting the extra effort the school have been putting in to talking about quality practices and agile methodologies. I heard that using test driven development is now a requirement on one of the MSc modules which is a good step forward.

The Winners

Another prize on the day was given to the best overall project and that team produced a software version of a chain reactive performance arpeggiator. They also had well structured, tested code and used a Kanban tool to manage their work in progress but it wasn’t quite enough to snatch our prize.

The winners of the Prize for Software Quality though were a team of 5 that produced a Greenhouse Appliances Control System. They used unit testing and had well named classes in a decent project structure. The key part of their project that stood out for us though was the collaboration they’d had with their customers and how well the team had self organised. You could tell that the team, who didn’t previously know each other, had formed a great relationship which showed in the quality of the software they produced.

As I’d been talking about software development being as much about people as it is about the code, the fact the winning team had found a customer (their University’s bio-sciences department) that had an actual need for their software seemed to help them enormously around prioritising and delivering features. A key point I noted was that they delivered an early, working, version of the software before most other teams which allowed them to get feedback from their supervisor and new customer. This helped them only produce the features needed, and appeared to give them chance to spend time on making the parts they did make at a higher level of quality. They also managed some pair programming which was evident when you could ask any member of the team about the software and they could answer with confidence.

One final aspect of this project that we liked too was the greenhouse simulator they made to test the tool during development was then further evolved to be a part of the product – adding another dimension and use case to the tool as a whole.

Alumni Talks

While we’d been discussing the importance of software quality and the methodologies we use for some time at the university we’d never had the influence of some of the bigger partners the university has at the alumni talks. This year though was different. Well done to the organisers as they managed to get alumni from Facebook, Google and the BBC. The real coup d’état for us (and Esendex) was that they all spoke about test driven development and software quality – falling over each other to recommend JUnit and Moquito. With much more well known names repeating our message, it really increased the effect of our prize and our motivations for creating it.

Conclusion

We had a great day out and are really pleased to strengthen our relationship with the University of Nottingham. Seeing an emphasis in software quality making its way into the early days of people’s careers in the industry is refreshing and bodes well for the future. As an organisation with greater than 50% technical people we’re grateful that graduates have access to teaching and practice around this better way of writing software so that we can seriously consider expanding our team with even more graduates in the future. As a society though, given software is even more prevalent in almost every aspect of our lives, I’m really pleased that future software will be written with quality in mind as the next generation of developers are inspired by the examples they’re able to see at universities like this.

More pictures from the day can be found on here.

I arrived at DevOps Days Paris not quite knowing what to expect. I’d been introduced to DevOps Days at the London event about six weeks ago, where I was blown away by the abundance of ideas and energy, and I was curious to see how this would play out in a different country and culture. Coffee and croissant in hand, I took my seat for the introductions. First up, a presentation about CustomerOps: using the DevOps obsessions about  visibility, metrics and communication to improve the consumer experience.

Next up, How ops improved my dev: the benefits of the DevOps culture as seen from the development side. My favourite bit of this was describing the inverse relationship between implementation and operational complexity; that is, things that are easier to set up often turn out to be much harder to maintain and troubleshoot. There was a nice example about a pipeline where data needed to be imported, processed, and encoded. The dev approach would tend towards writing one program to do all three tasks, keeping the majority of the information in memory. The ops approach would tend towards having three separate programs each with a single task, then if one part failed not only was it much easier to identify why, but also the other two could continue unaffected.

After a short break, we had a couple more talks, one of which was Transforming devs into devops. Ignoring the abuse of the term DevOps, it was interesting to me coming from the ops world to see what ops skills are perceived as covetable by developers: apparently this includes using linux as a development environment, git versioning and branching, scrum methodology, unit and functional testing. Now at least half of those I would have put as primarily dev skills, but maybe that’s because we’re all agile at our place. I was also quite pleased to hear the phrase ‘pair-devopsing’, which is an ugly term for a nice type of inter-team collaboration, and something we’ve been trying a version of at 7digital for a couple of months now.

The afternoon was devoted to Open Space sessions, where anyone can propose a topic that they want to talk about – usually something they want to know more about, rather than something they’re already good at. I went to an interesting discussion about Vagrant that I came away with two pages of notes about things I want to try out, and sat in on some interesting discussions about the clashes between teams with different priorities.

Our evening event was a dinner cruise down the Seine, followed by drinks at Cafe Six in town. A free bar always makes the conversation flow, and I was thrilled to not only sail past the Eiffel Tower twice, but also to take some snaps without dropping my camera overboard.

Back at the conference the next morning, the hangovers made the mood a little quieter, but the first presentation of the day was the excellent How we release software for GOV.UK, a project that I have been enormously impressed with lately. Their attitude of ‘digital services so good that people prefer to use them’ has lately earned them Design of the year 2013, and are an exciting example of how successful the DevOps approach can be: API access for everything, urls appendable with .json for consumption, fast release cycles, open source everything, archived versions made publicly available, and very blurry lines between developers and operations interests and responsibilities.

A couple more presentations followed, then a few ignite talks, including one from the CFEngine folks which touched on the need to abstract complex systems in order to be able to view problems from different perspectives, and then lunch. More open space sessions followed after lunch, before the scattering of the participants to the wind. I left with pages of notes of things to read, install, write about, and experiment with. Now I just need to find the time to do all of these things. If only I didn’t need to sleep.

On Thursday 31st Jan we held our first Devs in the ‘ditch event of 2013.

Paul Shannon convinced us that hiring a trainee is a beneficial action for almost all companies as well as the greater good of our profession. Using stats which highlight the huge imbalance between roles requiring greater than 2 years experience and those requiring less, he asks where these candidates are going to come from? Trainees can also come from diverse backgrounds, not necessarily computer science students but those with a demonstrable aptitude for it, or even from within other departments. This diversity is a valuable asset and also helps retain staff with domain knowledge. Paul then gave us a rundown of how we at 7digital are implementing our Technical Academy.

After a short break, where we took a few minutes to grab another beer and eat one of the tasty vegetable samosas or onion bhajis,  Gus Power took to the stage armed only with a pen and a whiteboard.  Gus gave us a quick history lesson of Agile and how it changed the focus from fixed time cost and features, with variable quality, to fixed time cost and quality with variable features.  He stated that there are many ‘non-functional’ requirements missing from most specs as they are much harder to quantify.  Gus has promised to write up his talk for people to read, which I hope he does because I realise that I am failing at effectively summarising it.  There is a small discussion about it going on at the Meetup page.

Gus Power armed only with a pen and whiteboard

On joining 7digital a year ago I published a short blog on my first fortnight with the new team. Now that our Technical Academy has been running for 2 weeks I’ve asked our 2 apprentices, Chris and Dan, to write a quick blog post about their experience so far. This is our first point in a series of regular feedback opportunities from our apprentices so we’re hoping to tailor the rest of their time here based on their positive and negative experiences so far.

The 7digital Apprentice Developers

Chris posted his “My First Fortnight” post on his personal blog: http://c24w.github.com/blog/2012/09/7digital-Technical-Academy-My-First-Fortnight/

Dan opted to post on the 7digital developers’ blog and his post is here: http://blogs.7digital.com/dev/2012/10/04/my-first-fortn…hnical-academy/

More on the Technical Academy

In early 2012 we were in a position to expand the development team but found that experienced developers, and especially those experienced in TDD, Agile, Lean and XP, were difficult to find. We also found that we were speaking to an increasing number of graduates and under-graduates when publicising the development team at various events, but often noticed a gap between the skills they were learning at University and the skills we’d like them to have. There has been some coverage around this topic recently with opinions from well known UK Software Craftsman Jason Gorman and mainstream media coverage from The Independent and The Next Web.

We decided to attempt to satisfy this need to train inexperienced new starters with a defined programme of classroom based sessions mixed in with the usual “on the job” training. You can see what we originally proposed to teach our new apprentices on the Technical Academy Jobs page although we’ve changed what we are doing based on feedback from teams. We like to continually improve our teams by inspecting and adapting all the practices we adopt and the Technical Academy is no different. This means we’ve added additional sessions on topics we thought we may not need to cover until later, but noticed that the apprentices had been involved in during their day to day work. Our emphasis is still very much on ensuring that apprentices can add business value right from the beginning so being able to adapt in this way ensures they do not slow down development in their respective teams. More on that in a later post.

In addition to the ability to hire less experienced programmers the academy also allows us to hire more diverse people. A good example is our current apprentice Dan, who studied Physics and Systems Biology, which brings a different view point on some of the practices we use, our product vision and the way we approach analytical tasks.

I have joined 7digital as part of the Technical Academy about two weeks ago and I started working in the API team. This is an appropriate stage to write down my first impressions here.

Setup

Setting up my work machine was not always straightforward, mostly with regards to networking and graphics. This is probably because I am working from a laptop, unlike most other Devs who work on desktops. I have made notes on the issues I encountered and will post them on the internal wiki so that new starters don’t have to go through the same difficulties I did. This would be in the spirit of continuous improvement at 7digital.

Classroom sessions

The main difference between the Technical Academy and a normal junior software development role is the inclusion of classroom sessions on the tools (such as C# and ReSharper) and development methods (such as TDD and Kanban) used at 7digital. The best point with these classes is how they are always relevant to the work performed. For example the class introducing mocking happened just after my pair programming partner of the day used it in code we were working on.

Open to different solutions and helpful environment

The team I got assigned to just started making a new internal website. We started to build it using a web framework none of us were very familiar with but was used by some other teams. Unfortunately it proved too difficult to use so we restarted with more familiar technology. Currently I feel like I have gotten up to speed with this project. This is due to the helpfulness of more senior members and the solid tests present in the codebase which allow us to easily verify changes.  Through the rotation of pair programming doubles, I find it interesting to see the small differences in the way people code with the two invariants being rigorous TDD and willingness to help.

Rollback

In another project my team released, we didn’t perform testing as thoroughly as we should have. This broke some of our client’s apps and required a late night rollback. Most of the following day my team worked a retrospective of the rollback. This retrospective involved finding out what caused the issues leading to the rollback and how similar issues could be avoided in the future. I found it great that the focus was on problem solving and improvement and not shifting blame.

Friendly office

The general workplace atmosphere is important and in that aspect 7digital does very well. Everyone is friendly and approachable and most interactions are informal. Furthermore the pace is set to be sustainable so working long hours is discouraged (but it doesn’t mean we don’t work hard).

Dan Kalotay