Developer guidelines that cut defects

Post-deployment defects down 20% year on year, for three years running.

Role: Governance lead ยท Platform: ServiceNow

Context

The team was new, and there were no development standards. Each developer used their own conventions, so every script read differently and things were hard to find.

Problem

Code became hard to read, and it was difficult to tell who had changed what. Development cycles ran longer, code reviews sometimes turned into disputes, and technical debt kept building.

Decision

We looked at better tools and more developers. But the real problem was rules and conventions, not capacity. If a bucket is leaking, pouring in more water won't help; it drains anyway. We needed to fix the bucket.

What we built

  • Coding standards and naming conventions.
  • Update set rules.
  • Code review standards, including how often reviews happen.
  • Development processes and checklists.

Result

  • Post-deployment defects, as logged in Jira, down 20% year on year for three years.
  • Less time spent in code reviews.
  • Faster to find custom scripts and work through update sets.

What I'd do differently

There is no one-size-fits-all framework. Next time I'd shape the guidelines around the organisation's own culture and practices from the start, and keep updating them as ServiceNow evolves.