Have you ever had one of those days when you run your program and it does the impossible?
As in, you stare at the screen and say: "No way, that's impossible. My program couldn't have done that. Couldn't be doing that."
It's a funny thing for a programmer to say, when you think about it.
We are logical people - or at least we are expected to use logic in our jobs.
And that is flat out a most illogical statement - contradictory on the face of it.
Because it wasn't impossible. Obviously. It just happened.
So what's a programmer to do?
Check your assumptions!
You must have made an assumption that is not valid. Assumed that data was in the table that was not - or vice versa. Assumed that you saved a change to your program that you did not. Assumed that you recompiled your program, when you had not. Etc., etc.
Here's an embarrassing true story from my own long, sordid history of programs doing the impossible due to my stubborn refusal to go back and revisit my assumptions.
Hopefully you've heard of the PL/SQL Challenge, a website offering weekly quizzes on SQL, PL/SQL, Database Design and Logic.
I built the website with lots of help from John Scott, Dimitri Gielis and Paul Broughton (all with APEX Evangelists back then). We planned to launch the site on 1 April 2010. And I promoted the site heavily. There was lots of excitement in the Oracle developer community.
New project by Steven! Let's check it out!
We started the site with a daily PL/SQL quiz (that's right - a daily quiz, which went on for four years. Lots of quizzes!), and each day started one second after midnight UTC time (formerly known as Greenwich Mean Time). So John and Dimitri and Finn (my co-founder of the PL/SQL Challenge) were waiting at their machines at midnight. It was 6 PM in Chicago. The second hand swept past 12 and the PL/SQL Challenge was born!
Hundreds of eager developers clicked the Start button to take the quiz - and the entire website froze. Like glacial ice. Sweat broke out on my forehead. I was frantic. Skype messages and calls flew furiously back and forth across the Atlantic.
What the heck was going on? We checked this, we checked that. We agonized. For hours.
And how could it be that with all these Oracle experts on hand, especially the amazing Steven Feuerstein, that we couldn't sort out the problem?
Well, the main problem, it turned out, is that John and Dimitri and Finn all trusted me to not be an idiot.
And at 4 AM, I was able to confirm that I was an idiot. Because I had issued a command to insert a row into a table, a row that was necessary for the site to work properly.
But I had not issued a commit.
I executed "COMMIT;" and the website unfroze. Bottlenecks disappeared. Quizzes could be played. And life did go on. The PL/SQL Challenge went on to attract thousands of developers, with between 500 and 1200 people playing each day for four years.
[We've since "settled down" to an array of 10+ weekly quizzes.]
And looking back on it, it's hard to believe that we couldn't diagnose the problem more quickly. Hard to believe that I could sit there insisting that I'd done everything I needed to do. And that there was no possibility of a data error.
Hard to believe that it happened, except that it did.
And it was a great reminder that when we are under lots of pressure, we don't always think as clearly as we could and should.
So what's a developer to do?
Make a checklist of all the assumptions you have made, and then go over those assumptions: True? Valid?
And once you've gone through that list, without getting to a resolution, ask yourself: what other assumptions am I making that I don't even realize I am making?
Hey, who ever said that programming was easy?
As in, you stare at the screen and say: "No way, that's impossible. My program couldn't have done that. Couldn't be doing that."
It's a funny thing for a programmer to say, when you think about it.
We are logical people - or at least we are expected to use logic in our jobs.
And that is flat out a most illogical statement - contradictory on the face of it.
Because it wasn't impossible. Obviously. It just happened.
So what's a programmer to do?
Check your assumptions!
You must have made an assumption that is not valid. Assumed that data was in the table that was not - or vice versa. Assumed that you saved a change to your program that you did not. Assumed that you recompiled your program, when you had not. Etc., etc.
Here's an embarrassing true story from my own long, sordid history of programs doing the impossible due to my stubborn refusal to go back and revisit my assumptions.
Hopefully you've heard of the PL/SQL Challenge, a website offering weekly quizzes on SQL, PL/SQL, Database Design and Logic.
I built the website with lots of help from John Scott, Dimitri Gielis and Paul Broughton (all with APEX Evangelists back then). We planned to launch the site on 1 April 2010. And I promoted the site heavily. There was lots of excitement in the Oracle developer community.
New project by Steven! Let's check it out!
We started the site with a daily PL/SQL quiz (that's right - a daily quiz, which went on for four years. Lots of quizzes!), and each day started one second after midnight UTC time (formerly known as Greenwich Mean Time). So John and Dimitri and Finn (my co-founder of the PL/SQL Challenge) were waiting at their machines at midnight. It was 6 PM in Chicago. The second hand swept past 12 and the PL/SQL Challenge was born!
Hundreds of eager developers clicked the Start button to take the quiz - and the entire website froze. Like glacial ice. Sweat broke out on my forehead. I was frantic. Skype messages and calls flew furiously back and forth across the Atlantic.
What the heck was going on? We checked this, we checked that. We agonized. For hours.
And how could it be that with all these Oracle experts on hand, especially the amazing Steven Feuerstein, that we couldn't sort out the problem?
Well, the main problem, it turned out, is that John and Dimitri and Finn all trusted me to not be an idiot.
And at 4 AM, I was able to confirm that I was an idiot. Because I had issued a command to insert a row into a table, a row that was necessary for the site to work properly.
But I had not issued a commit.
I executed "COMMIT;" and the website unfroze. Bottlenecks disappeared. Quizzes could be played. And life did go on. The PL/SQL Challenge went on to attract thousands of developers, with between 500 and 1200 people playing each day for four years.
[We've since "settled down" to an array of 10+ weekly quizzes.]
And looking back on it, it's hard to believe that we couldn't diagnose the problem more quickly. Hard to believe that I could sit there insisting that I'd done everything I needed to do. And that there was no possibility of a data error.
Hard to believe that it happened, except that it did.
And it was a great reminder that when we are under lots of pressure, we don't always think as clearly as we could and should.
So what's a developer to do?
Make a checklist of all the assumptions you have made, and then go over those assumptions: True? Valid?
And once you've gone through that list, without getting to a resolution, ask yourself: what other assumptions am I making that I don't even realize I am making?
Hey, who ever said that programming was easy?
Comments
Post a Comment