What Good Does Your Software Do?

If you can already write software without thinking about what good it does, then why bother with thinking about it? Because it will matter in the long run. If you choose not to think about it, you may still keep busy writing code, but you put the reasons why it turns out (or not) out of your hands. Things do happen to turn out. They can happen not to turn out as well.

To figure out what good some piece of software does or would do, you can ask yourself the following:

Question	What Good Answering Does You
"What if I did not have it?"	You will know what you would be missing.
"What will it do for me?"	You will know what it does, so you can ask why that is good.
"Why would I want that?"	The reasons why you would want it will be close to the reasons why it is good.

The more you ask and answer these questions, the better you will know what good software does, the better the projects and features you elect to work on will be, and the better the results will be for your efforts.

II.

What does it take to win at software?

Does success mean knowing hot tech and banging out code? No, not by itself. Code does nothing if no one uses it.

"Solve the right problems." Well, this is not good advice, even if one would like to follow it. This is more a criticism that can be made after the fact. What we want is something that we can use from the start.

So let's start again, suppose that: You could solve any problem put in front of you, yet for all the problems you have solved, you have not yet met with overall success. What to do? Assume that there do exist problems that you could solve, and if you were to solve them, then you would have success. And from that, what follows? Well, it is not simply to choose to solve them! Just because something exists somewhere, that does not mean that it happens to be right in front of you, waiting for you. Things are not got so cheap. Some kind of work must be done to get them.

The reality is that finding the right problems and asking good questions is a skill you develop, it is not a precept you elect to follow. This difference matters. Since it is a skill, you will have to learn it, have to practice, and may be bad at it in the beginning. That makes things tricky because your feedback loop may be weak to start with, which can be disheartening. You may well have to be consciously persistent and insistent about these things.

So, now, how to get started? "What is the question?" actually works surprisingly well to start with. Suppose you want to figure out what makes for success in software. What is the question?