The Four Questions
For any software project, where I am involved its development, I can ask four questions:
- 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?
- If I know what the software does or is intended to do, do I know and understand how
it does that?
- If the software has bugs (and almost all software has bugs), am I confident that any bugs can
easily be fixed?
- 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:
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.
- Is the software source code readable?
- Is the software well structured?
- Are program identifiers descriptive and informative?
- Is there test coverage?
- 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.
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
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
Super-Failed Projects: In the News
Sometimes software projects fail so badly that they hit the daily news. Especially if public tax-funded projects
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.