a blog about things that I've been thinking hard about

The Personal Software Quality Questionnaire

15 February, 2015
4 questions I ask myself

do I understand what the software does (or is supposed to do)?

do I understand how it does it?

do I believe that any bugs can easily be fixed?

have I done everything worth doing to answer "Yes" to the previous 3 questions?

The Four Questions

For any software project, where I am involved its development, I can ask four questions:

  1. Do I understand what the software does? Allowing for the possibility that the software is supposed to do one thing and actually does another, do I understand what the software is supposed to do?
  2. If I know what the software does or is intended to do, do I know and understand how it does that?
  3. If the software has bugs (and almost all software has bugs), am I confident that any bugs can easily be fixed?
  4. And finally, do I believe that everything has been done which is worth doing so that I can answer "Yes" to the previous three questions?

Comments on the Four Questions

Personal Side Projects

A personal "side project" is a software project that I do mostly for my own satisfaction and enjoyment. It's the type of project where my answers to all four questions are most likely to be "Yes".

If, for one of my side projects, any of the four questions does not have a "Yes" answer, then it should be very much part of the learning experience associated with that side project for me to find out why the answer isn't "Yes", and what I should be doing so that it can be "Yes".

I would go as far as saying that learning how to answer "Yes" to all four questions is the most single important benefit of doing personal software development side projects.

Other Developers

This questionnaire is by definition a personal questionnaire.

So as soon as more than one developer becomes involved in a project, there is a potential for different developers to give different answers to the same questions.

For example, let us suppose the existence of a fictional developer Derek (to the best of my knowledge I have never done software development with a real person called "Derek", so if your name is "Derek" and you are reading this, this is not about you).

Scenario 1: Derek looks at my software project

In the first instance, consider the scenario where Derek becomes exposed to one of my personal side projects, which to make things easy, I have posted to GitHub.

Derek can read my source code, he can run the unit tests (if I've written any), he can install the software and run it himself (if I've made it clear enough how to do those things). He can possibly find bugs in my software in the course of trying it out.

Derek hasn't yet done any actual development on this project – he hasn't yet touched the source code.

But he is already in a position to ask the four questions:

There are many reasons why Derek might answer "No" to some of these questions, even though I happily answer "Yes" when asking the same questions about the same project:

Scenario 2: I look at Derek's software project

Exactly the same issues can arise if I decide to look at one of Derek's side projects.

It may be that neither of us is "better" as a software developer than the other, yet it is not possible for either of us to be as confident about each other's software projects as we are about our own software projects.

Scenario 3: We both work on the same project

If myself and Derek cannot be confident about each other's projects, then the moment that we decide to work on the same project together, the possility arises that neither of us will have a satisfactory level of confidence in the quality of the software, even though that same software project is entirely the result of the efforts of the two of us, and no one else is involved.

Conversely, I would go as far as to say that a software collaboration between two software developers can only be considered fully successful if both software developers can answer "Yes" to all four questions, just as confidently as if they were answering those questions about their own individual personal projects.

The "pull request" mechanism can in principle make it easy for developers skeptical about each other's software quality to work together, if each developer only accepts a pull request when he or she can happily answer "Yes" four times with regard to the state of the software project after the pull request is accepted.

Super-Failed Projects: In the News

Sometimes software projects fail so badly that they hit the daily news. Especially if public tax-funded projects are involved.

Some project has been attempted, many developers were involved, but the end result is horribly broken, and no one seems to know how to fix it.

If I'm a developer, and I read about such a project, from a distance, I have to wonder – did the developers involved ask themselves something like the four questions in my personal quality questionnaire? And if so, what answers did they give? I would think, in most cases, that there are only two possibilities:

Vote for or comment on this article on Reddit or Hacker News ...