Convivio Cookbook
  • Introduction
  • Our Business
    • The Convivio brand
    • What do we do?
    • Our work for clients
    • Our Purpose
    • Our Pulse
      • Big Rocks
      • Problems
    • Company Policies
      • Environmental Policy
      • Anti-Bribery Policy
      • Fair Tax Policy
        • Dividends policy
        • 2020 Results and Tax
        • 2019 Results and Tax
        • 2018 Results and Tax
        • 2017 Results and Tax
  • Our Team
    • Help! I'm new. How do I get started?
    • Starting at Convivio
    • Staff Benefits
    • Being a buddy
    • Having a buddy
    • Free-Range Working
    • Convivio Fridays
    • Notes: give & receive feedback
    • Security Screening
    • Submit Expenses
    • Purchases
    • Your home working environment
    • People Analytics
    • Recruitment
      • Help Card: Writing a Person Profile
      • Help Card: Writing a Job Description and Advert
      • Help Card: Publishing a Job Advert
      • Help Card: Reviewing CVs
      • Help Card: Preparing and Conducting Structured Interviews
      • Help Card: Preparing and Conducting Remote Working Interviews
    • Team Policies
      • Security Policy
        • Acceptable Use Policy
        • Business Continuity Management
        • Data Usage Policy
        • Document Access Policy
        • Mobile Equipment Policy
        • Two-Factor Authentication (2FA)
        • VPN Guide
      • Equal Opportunities
      • Grievance Procedure
      • Disciplinary Procedure
    • Taking time off work
      • Holiday
      • Sickness
    • Peer reviews
    • Mental Health
      • Mental Health Training
      • Mental Health First Aid
      • Returning to work
      • Resources
    • Continuing Professional Development
      • CPD Annual Planning
      • CPD Sprints & Scrums
      • CPD Annual Review
      • CPD Annual Retrospective
  • Our Clients
    • Principles For Building New Client Relationships
    • Researching
    • Connecting
    • Nurturing
    • Assessing
    • Learning and Thinking
    • Pre-qualification questionnaires
    • Proposing
    • Agreeing
    • Beginning
    • Inspiration
  • Our Marketing
    • Content Publishing
      • Git Repository Conventions
      • Help Card: Writing a Case Study
    • Brand Guidelines
      • Content Guidelines
      • Branded Documents and Reports
  • Our Tools
    • Infrastructure
      • External Firewalls
  • Internal Projects
    • How we improve our business
  • Client Projects
    • Delivery Launch
    • Delivery Team
      • Convivio People
      • The Coach
      • User Researcher
      • Other Team Members
    • Digital Strategy
    • Discovery
      • Discovery Briefing
      • Discovery Planning
      • Discovery Modules
      • Discovery Findings
      • Discovery Principles
      • Prepare for prototyping
    • Prototyping
      • Inputs to Prototyping
      • Prototyping Objectives
      • Prototyping Inception
      • Prototyping Sprints
      • Prototyping Outputs
    • Build
      • Inputs to Build
      • Build Kickoff
      • User Stories
      • Backlog Management
      • Backlog Scouting
      • Sprint Planning
      • Sprinting
        • Daily Standup
        • Story Lifecycle
        • Design in Sprints
        • User Testing in Sprints
        • Quality Control in Sprints
      • Sprint Review
      • Sprint Retrospective
    • Service Management
    • Digital Service Standards
      • Delivery Methodologies
        • Scrum
        • Kanban
        • Lean
          • Technical Standards
        • Code Quality
        • Testing
        • Automation
          • Security Standards
          • Quality Standards
          • Risk Standards
    • Delivery Governance
      • Steering Group
      • Risk Management
        • Risk Attitude
        • Assessing Risks
    • Delivery Help Cards
      • Help Card - Sprint Planning
      • Help Card - Sprint Review
      • Help Card - Sprint Retrospective
      • Help Card - Product Owner Feedback
      • Help Card - Common Issues
      • Help Card - Slack
      • Help Card - Github
      • Help Card - Trello
  • Our Recipes
    • Convivio Classic Cocktails
      • Ingredients
      • Tips and Techniques
      • Martini
      • Negroni
      • Manhattan
      • Old Fashioned
    • Potage Dubarry (or, creamy cauliflower soup) with spiced green pepper
    • Roasted Sweet Potato in a Herb and Nut Salad, with Maple Chilli Dressing
    • Aubergine Curry
    • Vegetarian Paella
    • Easy Ice Cream
Powered by GitBook
On this page
  • Don't Write Code (write new code only when everything else fails)
  • Open source it
  • Quality matters
  • Version control is important
  • Don't do hard things, do easy things
  • Never build large apps
  • Programming is also teaching your team
  • The most important element of successful software development is learning
  1. Client Projects
  2. Digital Service Standards
  3. Delivery Methodologies

Code Quality

PreviousTechnical StandardsNextTesting

Last updated 7 years ago

Code quality is a way of referring to the quality of the product being built and the way that is being built – the product, the architecture, the design, the codebase, the technical team. It is a larger idea that covers many aspects of best practice when programming, when working in a technical team to develop products.

In that context, there's many best practices, methodologies, conventions and rules of thumb that we subscribe to here at Convivio.

Don't Write Code (write new code only when everything else fails)

This is the single most important lesson every developer needs to learn. The amount of duplicate, crappy code (across projects) that exists today is overwhelming. In a lot of cases developers don’t even bother to look around. They just want to write code.

(Source: )

Open source it

The manifestation of the 'Don't Write Code' mantra is that we believe in (OSS). By using OSS we are able to benefit from the uncountable hours of design and programming already invested by developers all over the world, and the only new code written is the necessary code.

We use OSS wherever possible, especially in product development, and consequently we participate in the open source community. Consequently and intentionally, we give back to the OSS community – sharing work, offering and reviewing patches for features or bugs, sharing knowledge, and so on.

We use for many projects so our largest interaction is with the Drupal community, but we also participate in the wider PHP community, as well as the frontend Javascript technology communities and others.

Quality matters

When I hear "JUST BANG OUT CODE THAT WORKS" I think of all the apps I don't use anymore because they gradually lost the ability to iterate.

(Source: )

working code > not-working code

But, it is better to work within the coding conventions of the technology you are using as this will tend towards high quality code. Coding conventions are there for good reasons:

  • they make code run well;

  • they make code readable when other developers come to use it;

  • conventions are often hard-won through brutal experience of writing efficient, effective portable code.

Code changes should always be reviewed. This includes:

  • peer review, through, for example, pull requests;

  • design and UX reviews;

    • automated testing, and

    • user testing.

Version control is important

If it is possible, we prefer to make our projects themselves open source.

Don't do hard things, do easy things

  • Simple is better than complex.

  • Complex is better than complicated.

  • Flat is better than nested.

  • Readability counts.

  • If the implementation is hard to explain, it's a bad idea.

  • If the implementation is easy to explain, it may be a good idea.

Never build large apps

The secret to building large apps is never build large apps. Break your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application.

Programming is also teaching your team

… a team of mediocre, inexperienced coders who work together and write for the benefit of the team has the capability to become a great team, and they can take that learning approach to create other great teams. It all comes down to whether the team sees its work as simply writing code... or writing with the goal of both code and learning."

The most important element of successful software development is learning

… when the entire team meets a certain standard for competence, there is a very large learning surface exposed and the team is able to absorb more information.

Sources:

For example, when working on Drupal projects we subscribe to the community-agreed .

, both:

With a number of developers working on a software project it is important that changes to the codebase are managed effectively. A version control tool is vital. There are a number of options, of course, but we prefer to work with where possible.

There are also good disciplines for branching models and workflows in version control. is what we usually prefer, but may be more appropriate in certain circumstances.

(Source: )

(Source: )

By splitting an application or product up into reusable components the components are individually testable and the application is testable as a whole. If we need to make a change, we can work on the component itself, test it, make changes, then regression test the whole application. ( – suites of independently deployable [distributed] services able to interact in a unified application – is the logical end of this approach.)

(Source: )

(Source: )

, ''

Naresh Jain, 'Biggest Stinkers', Managed Chaos blog
open source software
Drupal
Avdi Grimm
Drupal coding standards
testing
Git
Gitflow
other workflows
The Zen of Python
Brian Moschel, 'Organizing A jQuery Application'
Microservices
Joe Ottinger, 'Programming is Also Teaching Your Team'
Reginald Braithwaite, 'Which theory fits the evidence?'
Tim Oxley
Best Practices