ThoughtShapes Shaping Ideas With Thought

Believe nothing just because a so-called wise person said it. Believe nothing just because a belief is generally held. Believe nothing just because it is said in ancient books. Believe nothing just because it is said to be of divine origin. Believe nothing just because someone else believes it. Believe only what you yourself test and judge to be true.

~Buddha

Over recent years I've purposefully heightened my awareness to a condition in the software industry that I'll dub, "Assumptionitis." This usually occurs in a situation similar to the following:

1. Person "A" says something like "We don't want to throw exceptions in these situations because they incur a lot of overhead."
2. Because they are in a quick-speaking meeting and because they heard something long ago about exceptions having a lot of overhead, persons "B", "C", and "D" take what person "A" says and accept it. They may accept it only because it's hard to stop and purposefully analyze the statements that occur in such a meeting. Statements are thrown back-and-forth in meetings at such a pace that it's hard to even hear them all, much less reflect upon them. Nevertheless, acceptance is born.
3. A decision is made based upon person A's statement.
4. The team lives, designs, and codes with whatever decisions are made.

Learn to tune your ears to hear such folly, even if the assumption stems from your own mind. What do you do when your mind throws an alert to what your ears pick up on? Speak up and say, "We should probably validate that assumption," before you go ahead and write a test(s), of course.

Often these assumptions are performance based, and as such they are usually not worth paying attention to in the first place because one shouldn't optimize up front unless one is absolutely sure performance will truly suffer. For instance, one performance issue people often code around is copying collections. How many times have I seen people make a design decision based on the assumption that creating a copy of a collection will hurt the performance of the application? Too many. "Yeah, but I don't want to do it that way because I don't want to copy the collection."

Don't make such an assumption; write a test to see how long it takes your environment to copy a collection of an appropriate size...you might be very surprised. I know I was. When writing the test, write a test for the general case and then perhaps write a test for the specific context in which you are coding in. Also, even if it is only a test to validate/invalidate your assumptions, put the test in your project so it is there as proof of your validation.

And to touch upon something I've seen on .NET projects, don't worry about performance issues involved with using properties instead of direct field access; the performance "hit" is virtually nil, and using properties provides you with a point of extensibility well worth their use. If by some extremely unlikely chance that using a specific property causes a performance problem for the application, you can determine this later and then optimize at the latest possible time. It is certainly not worth losing the extensibility of properties because of an illusory fear of performance issues.

As for the above discussion of excessive worry about exception overhead, here is a great link.

Buddha quote provided by http://www.wisdomquotes.com/cat_truth.html.

Note: "Assumptionitis" is not solely relegated to the software industry. I encounter it every day, often emanating from my own mouth--usually when the topic is something I'm not completely familiar with (the reality is that I'm not completely familiar with anything in the universe, so this happens quite a bit). This phenomena, BTW, is where the title of this blog comes from.