RobDWaller A Developer


Rob Waller Profile Picture

I am a software developer and manager with nearly a decade and a half of experience. I also built Twitter's largest anti-bot app.

View My GitHub Profile

Tweet Me: @RobDWaller

Prove Your Code Works: Introduction

March 04, 2020 Home > Blogs > Prove Your Code Works: Introduction Author: Rob Waller Tags: code quality, documentation, tests, code analysis

One question I believe software developers need to ask themselves more often is, “Can I prove this code works?”

A professional software developer needs to provide guarantees their code will work when deployed to production. In a similar way a surgeon may provide guarantees they are competent to carry out an operation. For instance, by sharing certifications, references and surgery records.

Of course, no developer can guarantee their code is 100% bug free. Just as no surgeon can guarantee they will never make a mistake. But it should also be recognised statements like, “No-one has found a bug yet!” provide no guarantee of quality, prove nothing about a codebase and are completely unprofessional.

It is my feeling the software development industry needs to mature and take quality and professionalism more seriously. The work we do has an enormous impact on society, and as we all know has the potential to cause enormous harm too.

We need to move away from rushing half-baked ideas into production. We need to provide society with some guarantee what we produce meets some kind of professional standard. People expect their plumber and electrician to provide a guarantee of quality, so why not their developer?

Of course, to prove a codebase works and provide a guarantee of quality is no easy task, but it is more than feasible. The main way to prove a codebase works is to provide observability. This means to provide information about a codebase so it can be assessed without the need to look at the code directly.

This information will usually be an amalgamation of metrics, reports and documentation. Some developers may refer to this information as Service Level Indicators, and importantly this information should be as objective as possible.

If you haven’t considered observability or asked “can I prove this code works?” previously there are three areas you can begin with. They will help you guarantee the quality of you codebase and product.

  • Documentation
  • Tests
  • Code Analysis

I will write a short post on each and will link to them on this post and website. I may even turn these posts into a talk.

Please keep an eye out for them, and if you have any questions or thoughts please drop me a message @RobDWaller.