Writing software is hard, particularly when the schedules keep programmers “nose to the grindstone.” Every so often, it is important to take a breather and look around the world and discover what we can find-ironically, what we find can often help us write software better.

“I think, therefore I am.” Almost everyone knows of this quote, it seems, but few seem to understand what it means, or why it serves as an important reminder about building software.

If I tell you that, “The cat is on the mat,” what do you know?

Am I telling you that there is a feline resting on a small tapestry on the floor?

Am I simply making a nonsensical rhyme?

Am I telling you that there is a fact in the world, with or without any sort of supporting evidence, that we should discuss or debate?

Am I telling you that a particular feline, one which we've already discussed previously, is in a different location than what you'd assumed to be the case?

Am I disagreeing with your earlier statement that, in fact, it is an animal of the canine persuasion resting on the small tapestry?

Am I flat-out lying to you?

Or, even more disturbing, is the universe lying to you, and there is no cat, no mat, and not even an Earth for either of these two things to rest on?

Descartes was one of the first philosophers to deeply explore the philosophical concept of epistemology: the theory of knowledge. What can I know, and how? Does perception provide knowledge? What guarantee do I have of judgments based on memory? Is there knowledge of the past, of universal laws, of the future? Can knowledge reach beyond experience? And so on.

Descartes, and many of the other “skeptics” that followed, believed that in order to best get to the heart of what is and is not real, we needed to take basic beliefs and question them. For example, as I write this, I sit in an Old Spaghetti Factory on a rainy Seattle night, eating spaghetti with meat sauce and listening to the rain beat on the windows outside. Or am I? The skeptic would attack this statement on several levels, starting with the question “How do I know this?” I can certainly respond by saying, "I know this because my eyes see the Old Spaghetti Factory d�cor and logo, my ears hear the servers calling out �corner', my mouth tastes the sauce…."

But skeptics then ask, "But how do you know if you are dreaming? Can you trust your senses? Your senses carry electrical impulses to your brain for interpretation and processing, so how do you know you're not just a brain in a jar, with electrodes wired up against your sensory inputs, manipulated by an evil scientist, or demon (Descartes' favorite), or the machines?"

I won't pursue the whole line of, “How do you know you're not a brain in a vat?” further, except to say that, ultimately, Descartes' famous line is his assertion that because he can think, he can doubt, and therefore, if he can doubt, then the mere act of doubting indicates his own existence-even if everything else is in doubt, in order to doubt, I must exist).

Knowledge and… Code

What I do want to pursue is the notion of what we, as software developers, really know. When a developer comes up to you and says, “We have a bug in the code,” it can be important (and highly time-saving) to stop and play the skeptic: How does she know that? Has she proven that beyond any doubt, or has she perceived something that leads her to conclude that there might be a bug in the code?

If I see (or worse, when a user sees) a null appear in a field in which validation rules are supposed to screen out nulls from being entered, it can often lead us to a quick (and erroneous) conclusion that the input validation logic has a bug in it-after all, how could the null be there, otherwise? The validation logic executes when the user submits the form, and the null is there, so clearly the user-submitted data somehow got past the validation logic. There is no other way into the database, right?

Unless, of course, another group related to this project just ran an ETL (extract-transform-load) job to bulk-load a bunch of data from another data source, and our validation logic never got executed.

Or, that the null appearing on the display form is actually a bug in the display logic for that form, and the actual data still resides in the database, safe and snuggly warm.

Skepticism is a good thing, folks.

I watched an example of breakdown in skepticism play out once: An application we were building had suddenly, overnight, developed a serious bug in pulling up the data. No matter what data we tried to pull up, exceptions appeared. What was worse, this was-you guessed it-only happening in production. The VP, the Director of Operations, his system admin and the DBA lead were all clustered in a buddy's cubicle, peering over his shoulder at his code “which clearly was where the problem was.” Tense, snapping at one another, they were watching as he stepped through the code, when he noticed that there were extra spaces in the data columns-this was something that hadn't been there the day before. When he said this, the DBA lead murmured, “Oh, wait, I think I may know why that is,” and scurried off. Sure enough, when the DBAs had upgraded to a later version of the database modeling tool they were using to do database schema updates, the tool had decided to ensure that all the data fields were padded out to their maximum column width-and the DBAs had speced out their schema to be an extra couple of characters longer than our web forms were allowing, which was causing the exceptions.

Stopping to ask “What do we know and why do we know it?” would have prevented a very ugly confrontation between the maligned developer and the Director of Operations who insisted that it wasn't his DBA's fault for doing this-we should've been writing code to handle extra spaces everywhere.

(I won't disgrace this magazine with the full text of my buddy's response: suffice it to say it involved doing something biologically impossible.)

Knowledge and… Requirements

But skepticism plays a role on the other side of the development process, too: when a user says, “We need this feature,” how do we know that they need this feature? Do they “need” it, or “want” it? How do they know that they need it? And what do they mean by the feature in question? I suspect that every software developer on the planet has fallen victim to Requirements Fraud: During the requirements/story gathering, a user says, “We need X” and the developers faithfully go off and estimate, implement and deliver X, only to hear other users say, “Wow, we waited all that time and all we got was X?” Further investigation reveals X to be a feature that only that one particular user wanted, and the rest of the group really wanted features Y or Z.

I'm not going to suggest that users lie (though the great philosopher Dr. Gregory House would quickly point out that everybody lies, and you're an idiot if you believe otherwise), but frankly, users can be just as mistaken about what the rest of their group wants as we can. Sometimes, asking them how they know that said feature is needed can help eliminate some of those accidental gold-plating exercises.

As a follow-on exercise, sometimes asking “Why?” can lead a developer to discover the reason behind a feature. That can, in turn, lead the developer to make suggestions that better the users' lives, because users often don't know what's technically possible, only what (they think) they want.

Knowledge and… Products

This one should, probably, be obvious to every developer already: when a vendor shows up and says, “Our tool makes your developers 500% more productive!” your first response should be, “Oh, REALLY. Hmm. How?” A healthy skepticism about vendor sales pitches and product demos is often the difference between a six-figure purchase that leads to a VP or CTO's termination, and a six-figure purchase that leads to a VP or CTO being interviewed on the cover of Wired.

Skepticism about Skepticism

Unfortunately, being a skeptic is widely viewed as a negative trait: you're not a “team player,” you're “too negative all the time,” and you're “affecting the team's morale.” It seems that to some, the act of trying to drill down on what we know and why we know it and how we discovered it is some kind of sin. And, unfortunately, trying to convince them that going through this exercise can be a task reminiscent of Sisyphus-the best thing to do is to patiently explain why skepticism can be of benefit to everyone in the long run, and if that still doesn't carry much weight, then just live with the moniker “Grumpy Old Man” of the company, and know that in the end, you'll be vindicated.

I usually am, anyway.

(For those interested in a light introduction to skepticism, I highly recommend the book Modern Philosophy. Thanks to Risa Kawchuk for her help in reviewing this article and keeping it on a philosophically-accurate straight-and-narrow.)