Skip to main content

Software Engineering Principles

At Cancer Research UK, we work in multi-disciplinary, cross-functional, and empowered technology teams. This means we may take different approaches to delivering value, and that flexibility is a strength. However, as software engineers, it’s important to have a shared foundation — a set of principles that guide how we build, collaborate, and continuously improve. These principles help us align on what great software development looks like while allowing teams to work in ways that suit them best. These principles are not rules, but they reflect our collective experience and the values that underpin our success.

Write simple, high-quality code​

Code is our craft, and clarity is key. It’s ultimately what we’re here to do.

  • Prioritise readability and maintainability over cleverness.
  • Follow best practices and established coding standards.
  • Keep things simple—if it’s hard to explain, it’s probably too complex.

Example: When implementing new features, focus on writing code that is easy to understand and maintain. Avoid unnecessary complexity, abstractions or over-engineering. Adhere to established coding standards.

Prioritise supporter value​

Every line of code we write should be with value to the supporter at the forefront of our minds.

  • Build with the end user in mind—whether a researcher, fundraiser, or supporter.
  • Focus on value, not just delivery—does this feature make a real difference?
  • Consider accessibility, performance, and inclusivity in everything we create.

Example: Before starting development, consider how your work will impact supporters. Ensure that features align with user needs and provide genuine value.

Embrace collective responsibility​

We succeed, fail, grow and learn as a team.

  • Success and failure are shared—we support each other.
  • Help colleagues through pair programming, knowledge-sharing, and mentoring.
  • If you see something that can be improved, step up—it’s everyone’s responsibility.

Example: Collaborate with team members, share knowledge, and support each other in overcoming challenges.

Mistakes are Learning Opportunities​

A culture of safety enables innovation and growth. We should be working in safe spaces, where mistakes are ways of learning.

  • No blame, just learning—failures should lead to insights, not finger-pointing.
  • Take ownership, reflect on what went wrong, and adapt.
  • Create a safe space where experimenting is encouraged.

Example: If an error occurs, conduct a blameless retrospective to understand the root cause and implement improvements.

Seek to improve by trying new things​

Curiosity and experimentation drive progress.

  • Stay open to new ideas, tools, and techniques.
  • Be proactive in your learning — seek out opportunities to grow.
  • If you see inefficiencies, challenge the status quo and suggest better ways.

Example: Explore new technologies or methodologies that could enhance your work. Attend workshops or engage in continuous learning opportunities. Attend of Give talks and experiment, experiment, experiment!

Challenge and Be Challenged​

We grow by questioning assumptions and engaging in healthy debate.

  • Ask why and expect to be asked the same.
  • Give and receive constructive, well-intentioned feedback.
  • Be open to change — great ideas come from open minds.

Example: Provide constructive feedback during code reviews and be open to discussions that question existing approaches. Respectfully challenge decisions and be ready to have your own views challenged.

Automate Where Possible​

Manual, repetitive tasks slow us down—automation helps us move faster and smarter.

  • Automate testing, deployments, and infrastructure to reduce toil and improve reliability.
  • Use CI/CD pipelines to ensure fast, safe, and repeatable software delivery.
  • Focus on developer experience—automation should make our lives easier, not harder.

Example: Set up automated test suites to catch issues early rather than relying on manual testing.

Design for Scalability and Resilience​

Software should be built to scale and handle failure gracefully.

  • Think beyond immediate needs — how will this system perform under increased load?
  • Embrace fault tolerance — design systems that can recover from failures automatically.
  • Follow observability best practices—logs, metrics, and alerts should provide clear insights.

Example: Ensure your service gracefully degrades when dependencies fail, rather than breaking completely.

Bias for Action, but Validate Assumptions​

We value learning through doing, but we also validate before committing to big decisions.

  • Don’t let perfect be the enemy of good—ship small, valuable changes often.
  • Use data and feedback to validate ideas before investing heavily.
  • Experiment with prototypes and proofs of concept before scaling solutions.

Example: If considering a major refactor, test assumptions with a small-scale proof of concept first.

Build Secure and Ethical Software​

We are responsible for the integrity, security, and ethics of the technology we build.

  • Follow secure coding practices—security isn’t an afterthought.
  • Consider privacy and data protection in every decision.
  • Build ethical AI and software—be mindful of unintended consequences and biases.

Example: Before launching a new feature, ask: Have we considered the security implications and data privacy risks?

Document What Matters, Make Knowledge Accessible​

Good documentation makes great teams even better.

  • Keep documentation concise, useful, and up-to-date.
  • Make knowledge sharing a habit, not an afterthought.
  • Favour self-documenting code and automated documentation where possible.

Example: If onboarding a new engineer would be painful due to a lack of documentation, the team should improve it proactively.

Balance Innovation with Sustainability​

We want to push boundaries, but we also need to maintain what we build.

  • Be mindful of long-term technical debt—cutting corners today can cost us later.
  • Refactoring is part of development, not an afterthought.
  • Strike a balance between exploration and maintaining stability.

Example: If a new framework looks exciting, consider whether it has long-term support and aligns with team capabilities before adopting it.

Putting These Principles Into Action​

These principles aren’t about enforcing rules—they’re about fostering a strong, collaborative engineering culture. Most teams already embrace them in some form. Use them as a guide to align on how we build software that makes a difference.