Decisive Points of Time

Last time I was in Finland in January I held a few trainings and in one I started to diagram something for the first time. I had been thinking about it for months, but had never made anything concrete out of it. So why not do it before a live audience? I guess the diagram didn't turn out to be perfect but I hope it got the message through. Let me explain this:

I wanted to show how the amount of choice diminishes with time. Let's assume your customer finds a mistake in your program. It does happen, you know. What are your choices after that? You have just one choice, fix it. Right? Leaving out the quite realistic option of ignoring errors, let's just assume that this is something so serious, you can't ignore. So you have only one option. Did you ever have more?

If you retrace your steps before the customer found the error, you'll notice that it would have been better for your reputation and your program had you or your team discovered the error before the customer. But did you have any other options, then either? If your test team, how internal ever, finds an error, you have to fix it. There's only one option, especially if it is serious enough to worry your customer. Let's go back in time some more.

How far should we go until the number of options changes? How long do you only have one option, fixing the error? The answer leads us right back to the time when you are just committing the error. After that there's only one course of action left for you. Removing the error, fixing it, getting rid of the fault, however you want to call it. The sooner you do that, the better. The best thing that can happen AFTER you commit a mistake is to notice it yourself. You'll be the only one to suffer, which is quite correct as you were the one to commit the mistake in the first place. The next best thing is if one of your peers notices the error in routine code inspection. It seems to be acceptable if it is the internal test team or even an external test team to notice the error. As long as you can fix it before the customer sees it, seems to be acceptable. The world doesn't always end with the customer noticing a serious bug, and just sometimes even serious bugs slip through without anybody noticing. Whether that's good or not, I can't say. Sounds like a zen-type question. How serious is a fatal bug nobody notices? Compare with "if a tree falls in the forest and there's nobody there, does it make a sound?"

Ok, after committing a mistake, you only have one course of action open to you. You have more choices BEFORE making a mistake. You can choose to work as normal, accepting that errors are normal and hoping that somebody will catch the most serious ones before the customer. You can always complain loudly that there are not enough testers in your project and that is jeopardizing the whole project. You'd do a good job but the company is not willing to invest in testing enough, so you're not responsible.

The other alternative is to take responsibility for your output, in this case your code, and do everything in your power trying to prevent errors from happening. That could be a regular Tick-the-Code session, where you lower the complexity of the code overall without ever noticing any errors. With lowered complexity you raise the possibility that you notice errors just as you make them. With clearer yode you also are less likely to make errors at all. A gaping hole in the logic needs filling and is clear to see if your code is structured in a clear and standard way, opposed to being a mess of spaghetti code where it is extremely difficult to notice anything missing because of all the extra baggage complicating the picture.

Regular code inspections prevent you from making mistakes and you never have to pass beyond the Point of No Return. Tick-the-Code gives you the Power of Choice. Take responsibility and decide for yourself. Don't let errors do the driving. Be proactive and remove errors without even making them in the first place. That is truly the Best Option.

As a graphic I tried to present this as two converging lines from left to right (the two choices: The High Road to Quality and the Wide Road to Mediocrity), which would meet at the point in time of committing a mistake, after which they would continue with time as just one line, one course of action. On that line you'd have people noticing the error and eventually somebody, you perhaps, removing the error. As a matter of fact, it is like the letter "Y" turned 90 degrees counterclockwise.

I'd be interested in any comments on this highly practical, yet philosophical, software-technological thought construct. How yould we utilise this, if we assume it is true? Is it true? If you thought like that, would you act differently? Do you think like that? Do you try to maximise options in your work? In your life? Or are you minimizing them routinely? Or does the right course of action depend on the subject matter? Let me know your thoughts on this, dear reader.