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

• These questions do not say anything about the specifics of source quality, such as:
  • Is the software source code readable?
  • Is the software well structured?
  • Are program identifiers descriptive and informative?
  • Is there test coverage?
  These specific items are often relevant to answering the four questions in the questionnaire, but given the wide variation in the circumstances of software development, and the variation in the personal knowledge and beliefs of different software developers, it would be presumptive to enforce their inclusion into any of the questions.
• The fourth question is more open-ended, even than the first three. Depending on the circumstances of a software project, it may or may not be worth putting effort into certain things. For example, for a throwaway experimental project, it may not be worth writing a lot of unit tests, or any at all. At the same time, as the project evolves, perhaps from experimental "throwaway" to something practically beneficial and widely used, it might be necessary to add in the missing unit tests so that the fourth question can continue to deserve a "Yes" answer.

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:

• He can ask it he knows what my software does, or at least what I intend it to do.
• He can ask if he understands how my software works.
• He can have some opinion on whether it will be easy to fix any bugs that might exist.
• He can ask, in the context of his own intended use of the software, whether I have put enough effort into the quality of my software, or whether he might have to expend additional effort to get the software to a level where he can confidently answer "Yes" to those three questions with respect to how he intends to use my software and what he intends to use it for.

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:

• Critical elements of explanation about what the software does and how it does it might exist only "in my head", because I never properly wrote them down.
• Derek might have different ideas to me about how software source code should be structured, and how things like variables and functions should be named.
• Derek's approach to debugging software may be different to mine.
• Derek might know things that I don't know about software, or about the particular functionality addressed by my software, which makes him less confident about the software's quality and fitness for purpose. In other words, in my ignorance, I may be over-confident about the quality of my software.
• Derek might know less then me about certain things, and until he learns those things (which need to be learned outside the context of my specific software application), he can't be confident for himself that he knows what the software does, how it does it, and that any possible bugs won't be too hard to fix.

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:

• The developer asked him/her self the four questions, and answered "Yes". Unfortunately, due to lack of skill, knowledge or experience, the developer was deluded, and, if wiser, the developer would have answered "No" to at least some of the four questions.
• The developer asked him/her self the four questions, and answered "No" to some or all of them. Unfortunately, due to how the software development was structured and managed, that developer's personal opinion about their confidence in the quality of the software was completely irrelevant to the processes used to develop and release the software in question.