Joost Visser
Dec 1, 2016 · 3 min read

On Wednesday, the tech startup open-sourced the software code and robotics research platform for their driver-assistance system.


They decided to do so in response to regulatory pressure from the National Highway Traffic Safety Administration (NHTSA). In short, by open sourcing the software rather than bringing it to market in a product, they can unleash the innovative power of open source contributors across the globe, without suffering the burden of product safety red tape.

What is the quality of the code?

So now that the software is open, let’s look at the code quality. My favourite code quality tool is the Better Code Hub (full disclosure: my team built it). It took me about 2 minutes to head over to GitHub, fork the repository to my own GitHub account, press the Better Code Hub play button, and here we are:

The source code of openpilot complies to 3 out of the 10 guidelines for building maintainable software.

Ok, that does not look so great!

The code base is nice and small (Guideline #8), it is divided into a balanced set of top-level components (Guideline #7), and it sticks to basic rules of code hygiene (Guideline #10). On the other guidelines, there’s work to do.

Does maintainability of openpilot source code matter?

Code that is maintainable can be easily understood, verified, fixed, and enhanced by others. The code of openpilot will be the basis for a flurry of innovation by contributors around the globe. The better the code, the faster they will innovate, the fewer mistakes they will make, the more confidence they can get from code reviewers and users. So yes, maintainability matters.

Any good news?

Low code quality is actually quite common. The good news is that we can effectively make it better:

  • We have the tools to get code quality right. Since the Better Code Hub is free for open source software, anyone can identify and work on those areas of the code that need improvement.
  • There’s plenty of knowledge we can tap into to drive software quality into the future. For example, pick up your copy of Building Maintainable Software to read about the 10 guidelines for writing future-proof code, including basic strategies to refactor code that is not compliant.
  • And of course there is the nearly unbounded talent of many motivated, creative, intelligent software developers that love to create high quality products. All they need is a clear, actionable definition of done for software quality.

Deep code visibility

The world runs on software, not just your car. Making software open source provides an excellent opportunity for making code quality visible, as I showed above with Better Code Hub. Similar visibility is needed for quality of proprietary code so that developers, reviewers, regulators, and users can collaborate to produce software products we can rely on.

Joost Visser is CTO at the Software Improvement Group, Professor of Large-scale Software Systems at Radboud University Nijmegen, and author of O’Reilly books “Building Maintainable Software” and “Building Software Teams”.


To get access to Better Code Hub while in beta, just go to, click the [Pro] button and then [Request Access] to send them your GitHub handle for whitelisting.

Write BetterCode

The Definition of Done for Product Quality: Improve what Matters with

Joost Visser

Written by

Write BetterCode

The Definition of Done for Product Quality: Improve what Matters with

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade