Introducing our software development standards

There are many software engineers across Co-op Digital – they’re responsible for building our products and services. Because they’re all great and eager to build things well, it’s easy to assume that everyone will build things in the ‘right’ way.

However, that’s a risky assumption and it’s not always the case. Instead of leaving it to chance, Ian Waghorne, Andrew Liddell and myself started to create software development standards and pin down Co-op Digital’s previously unwritten guidelines.

Our aim was to come up with a set of software development standards that:

  • could be used across Co-op Digital
  • take into account the uniqueness of Co-op products, services and platforms
  • could potentially be used throughout the Co-op Group

The benefit of having a set of standards is to make sure engineers don’t move too far off track and build things in a way that their stakeholders aren’t comfortable with.

We started small and got feedback quickly

The 3 of us quickly compiled a set of standards. They were short notes, just enough to get feedback. When we shared them with the other engineers intense discussion followed and the feedback was that we’d been too prescriptive.

At Co-op we have many different services at various stages of their life cycle, each with different contexts. The feedback had told us that (fairly obviously) one size wouldn’t fit all – or rather, a set of standards with narrow and rigid boundaries wouldn’t fit all. The engineers working on certain services needed more flexibility to get the job done effectively.

Balancing flexibility with governance

The main challenge was making sure the standards were flexible and worked for our engineers but still met our wider stakeholders’ needs. What we needed was just enough governance to allow us to keep working quickly, while providing a good level of reassurance that we were not exposing the Co-op to an uncomfortable level of risk. We coined the term ‘outer governance’ to help us frame this.

Striving for clear, concise standards

We think that figuring out whether your product or service meets each of the standards should be through a conversation both within a development team and between the team and other stakeholders. To help facilitate the conversation, we thought carefully about how to word the standards so there’s less room for misinterpretation.

So, each standard contains:

  • a ‘motivation’ to explain why this aspect is important
  • a brief explanation of the standard with an example
  • a few questions to help teams assess the state of their product or service

Standards can be quite abstract and we felt that including the questions would help people really consider how each standard applies to their work.

Software standards could help us assess the condition of a service

In software development, teams often build up levels of ‘technical debt’. Technical debt happens when we choose a lower-quality solution in order to deliver sooner and get quicker feedback on whether something works. You could think of it as the equivalent of a business borrowing money to get its product to market sooner. Although taking on an amount of technical debt is a common practice in the technical world, we need to be sensible because it means we’re taking on more risk. Like any debt, technical debt needs to be incurred intentionally, managed carefully and, most importantly, paid off at some point.

Quite rightly, stakeholders want to know about the level of risk involved in a project but in most cases, they’re not digital experts. We believe that software standards can be used to provide a consistent view on the technical debt being carried by a service. By rating each standard for a given service we can provide a view of technical debt at a level that stakeholders can understand.

Rick Healy and I have been working on how we can represent this in a clear and simple way. Our next step is to try it out on some of our services and see what it tells us and if it’s helpful for those services’ stakeholders.

Screen Shot 2018-06-25 at 10.09.57 The Assessment Wheel

Engineers, we’d like your feedback

You can read our software development standards.

This is just the first version and we’ll be iterating them as our teams use them. We’re keen to hear feedback from internal and external digital teams and in particular engineers so let us know what you think below.

Andy Longshaw
Principal Software Engineer and Tech Lead on Co-op Guardian

Lesson learnt: test in context as soon as possible

I’m holding my hands up and admitting my team recently made a mistake. We’re guilty of using high-tech laptops to build software intended to run on far less powerful devices.

Testing in context is something all digital teams should do automatically. But while chatting to a couple of other software engineers, I learnt that forgetting to do this is a common developer sin. Or at least, it’s more common than it should be.

I hope that by writing this post it’ll help keep it in the forefront of people’s minds.

What we were working on

I’m part of the Membership team. Recently, we wanted to find out if members would find it useful to check their rewards balance at the start of a shopping trip, so we’ve been building a prototype that members can use in stores.

Where we fell down

The prototype we were building was difficult to run on the device we’d be testing it on, ie, the small Android tablets in stores. The tablets weren’t chosen for their performance, they were chosen so we can keep the cost down while we’re still experimenting. To make the prototype run faster, we’d been using the browser on my laptop while we we doing the development work and showing demos to the team. In other words, we’d prioritised speed over accuracy.

A few days after spinning up the prototype, we tried it on one of the tablets. It didn’t work in the same way. We’d wanted to get it into the hands of real users as soon as possible so we could check our assumptions and find out how well it met user needs so by this point we’d booked in some user testing in store. Unfortunately, we couldn’t fix it in time.

Not a disaster, just a delay

Working in an agile way allows us to overlook relatively small things and make little mistakes like this. The beauty of agile means we’re never going to spend an outrageous amount of time or money correcting mega problems. For our team, we had to delay the user testing which was frustrating (we should’ve known better), but it wasn’t a disaster.

Easy to fix

We spent a day accounting for the differences between the Android tablet and the browser on my machine. We used a service called ngrok.io so the tablet could use the website running on my laptop and we could develop against the low-powered device. This way we could test over a representative 3G network. It’s what we should have done all along.

But easy to avoid too

As I said, testing prototypes in context or in an environment as close to reality as possible is basic but sometimes, for whatever reason, there’ll be occasions when we trip up.

To avoid this:

  • keep in mind the device, or types of devices, your users will be using your product or service on, both before and after you begin building (this is the big one, obviously)
  • involve your quality assurance testers (QAs) as early and as frequently as possible
  • run the software on realistic devices as early and as often as possible…
  • …but never assume that emulating a device in a browser will be exactly the same as it would on a device

We’ve learnt our lesson. Let this be a reminder to you!

Paul D’Ambra
Software engineer

Adam Westbrook: life as a platform engineer at Co-op Digital

(Transcript) Adam Westbrook: So I’m a platform engineer here at Co-op Digital. I’ve been here 3, 4 months now. Day-to-day we sort of work with the development teams and the service teams and stuff like that: building out new infrastructure projects, working with the development teams on new products for membership.

There’s lots of opportunities for engineers around here to work with big engineering teams and stuff like that but there’s no other kind of companies around here they’re owned by their members and doing stuff that Co-op does for local causes and so it’s not just a normal big engineering team at a big company. You’re contributing to something a bit more.

It’s really good having everyone on one very open floor, we’re all working together, we’re able to proof of concept new products really quickly and just the of level of communication up here is really good, everyone can speak to each other, everyone knows each other everyone’s close and it’s just a really sort of good environment to get stuff done in.

So I think the thing that most enjoy about working here is being able to work with the other engineers and the other parts of Co-op Digital to really sort of push out new products and projects and things like that, really quickly. It’s a really great team here. The work that we do is really good and as such a focus on people working together and collaboratively and sort of learning and developing from each other and that’s often really difficult to come by. And just the culture here is really good that promoting that.

Adam Westbrook
Platform engineer

Life as a software engineer in Co-op Digital

Software Engineer Nancy Richardson shares her thoughts about working in the Digital team.

(Transcript) Nancy Richardson: What I love about working here at Co-op Digital is I feel that at the end of the day that I’m making a difference. The products that we have are very well thought out and I’m also excited about the future as I’ve heard of some of the things that Co-op could be working on in say five years from now. Also I enjoy the diversity of the people I work with, we’re all different ages, different backgrounds.

I was attracted to the role because of its full stack and polyglot approach. This makes the work very varied, you could be working in the front end, back end, or on DevOps, and every sprint could be focusing on a different area of the stack, so this makes it very interesting. And I come from a Ruby background but now i’m learning Java which is really different from ruby but I feel very supported.

I’m learning from my colleagues on the job and there are also code show and tells. There’s even dedicated learning time. I think now is a really good time to join the Co-op because Co-op Digital is starting to expand so you have more influence in helping develop our standards, our ways of working, our teams stack and our practices.

Nancy Richardson
Software Engineer (Membership)

We’re looking for engineers at the moment. If you’re interested take a look at our Work with us page.

 

Simon Stead: life as a software engineer at Co-op Digital


(Transcript) Simon Stead: My name is Simon. I’m a software engineer and I work on the Digital team that works with Food in Co-op.

So I already knew a few people who worked at the Co-op from my last job and they told me how fantastic it was to work here, how nice everyone was so I thought I’d apply and then I managed to get in.

We’re working on a multidisciplinary team so there’s me, some other software engineers, but it’s lots of user researchers, interaction designers, content designers, delivery managers, everyone is just pooling all of their resources and sharing all of the work and just getting your hands dirty at the same time.

So we’ll all be sat on the same table and I don’t often feel like a software developer because we’re all just trying to solve a common problem together. If that’s data, if that’s design, if that’s dev, if that’s user research we all pitch in and do a lot of the same stuff together.

I think the best thing I like about working at Co-op is that I can just try new things all the time, I get so many new opportunities and I get to engage with so many different people, be that people in Co-op Digital in the Food business, different stakeholders, area managers, store managers, whoever they may be.

I’m autistic, I’ve got Asperger’s syndrome and so one of the really nice things about working at Co-op and Digital is that I know I’ve got a wealth of support behind me so if there’s any problems I’m having I know I can talk to whoever I need to to solve that. If I need flexible working hours or anything like that it’s just all available here.

So we work over here at Federation and we also work over in Angel Square but Federation, the open space, the air, the light, the colour, the beanbags, everything just makes it such a nice open place to work and I feel like that really gets reflected in the digital products and services that we build.

Working at Co-op, I always thought I’d be the kind of person who would just like hop from job to job and never really stick to one place but I honestly can’t see any reason that I’ll be leaving anytime soon.

Simon Stead
Software engineer

We’re hiring software engineers. Find out more and apply.

What it’s like working in Digital Engineering

Gemma Cameron, our Principal Software Engineer speaks about what it’s like to work in Co-op Digital and Digital Engineering.

(Transcript) Gemma: I love the variety of projects that we have going on and all the people that are working on them. So we’ve got not just amazing engineers, we’ve also have got some really great product owners, delivery managers, really amazing BAs and the designers are just incredible and we’ve got all the user experience team.

We’ve got some great people working on really innovative cool projects and, you know, what comes out of it is actually doing something good.

I’m supported in all the community stuff that I do outside of work. So I get to you know, Co-op are helping out with Hack Manchester so we support and sponsor Hack Manchester, I also get to run events here, we are sponsoring the Liverpool Girl Geeks Academy, so it’s great getting girls who are like 12-14 to get to some experience programming.

We sponsor events, we attend events, so we were at the Manchester Digital Skills Festival not so long ago and that’s great meeting some of the new graduates and people are looking for work and getting to tell them about the story of what we do here, that we’re bringing brilliant people in who are really good at collaboration, who really care about software quality and you know we’re doing all the good things like test-driven development.

We’re building these great teams but we don’t expect everybody to know all the tools that we’re using or the languages that we’re using. So we have got some people who showing all these great people and behavioural qualities, but they’re not so good on Java and we’re giving them time and space and we’re coming up with a syllabus to give them that training.

The same with test-driven development and looking at all that quality. We have community of practice and we get together as a group of engineers and work out what our, sort of, level of quality should be. I also want to try and see if I can get involved in some of the projects from inception so actually working together with people and talking to them about what their needs are, going to have discovery phase and creating like little alphas that would be awesome because I’ve worked in a start ups before and I enjoyed doing that experience and it would be nice to do it for a more worthwhile cause.

Gemma Cameron
Principal Software Engineer

We’re looking for software engineers right now. Join us.

Making better, joined-up decisions with the engineering community

This month, it’s 3 months since we set up our engineering community for software engineers, platform engineers, service managers and quality analysts at the Co-op. It’s early days but it’s already helping move Co-op engineering in the right direction.

Getting together with people who do similar jobs helps us all be more joined up which is really important, especially in a place as big as the Co-op. Without a community, we’d be working in isolation because our day jobs are within Co-op Digital, Co-op Legal Services or Funeralcare.

When we began meeting regularly, we identified the areas we need to work together to develop, including how we support training and development and coming up with development standards.

Picture of our Engineering community of practice

We’ve created infrastructure standards

I was really pleased to see that practices such as Continuous Delivery and Infrastructure as Code were already well established when I joined Co-op Digital 6 months ago. However teams were working in isolation at that point. Lots of them had similar problems and were tackling them in different ways. This meant that getting some of the services we were launching to a point where they were secure, reliable and supported was trickier than it needed to be because there was quite a bit of rework involved.

To make things simpler, we spent time during our community of practice meet-ups to create shared standards for our platform infrastructure. There’s still plenty to do and these things are never really finished of course, but we’re now in a much better shape and future projects will follow a much easier path. Most importantly, teams are more empowered to get on with stuff and do their job.

We’re also working on standards for how we’ll support cloud infrastructure across several teams. This work will sit with our Digital Operations team which is forming steadily.

Making better technology decisions

Out of that also came a clear need to provide better support around making technology decisions. We want teams to be empowered, but at the same time there’s always going to be a limit on how many different technologies we can support and maintain. Our approach has been to try and provide really great guidance so teams can make decisions in context rather than needing meetings to make decisions. It’s all still quite early days so again we’ll hopefully come back again soon and update on how it’s getting on.

We’ve been hiring

C6VVNKlWgAMmd3r

We’ve worked with some great external companies while we’ve been adding gradually to our in-house expertise but we’re at a stage now where we’re looking to bring in a significant number of software and platform engineers. The Co-op Digital team and the wider engineering community of practice is looking forward to new talent joining us. From there, the culture of the team will grow and strengthen.

If you’re interested, take a look at our Work with us page for the roles we currently have open. We’ll be recruiting for engineers for the Funeralcare team shortly.

In the meantime, sign up to the blog and follow Co-op Digital on Twitter.

Rob Bowley
Head of Engineering