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

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.