Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius--and a lot of courage--to move in the opposite direction. --Albert Einstein

I have always believed in Einsten's quote. There is a related one:

Everything should be as simple as possible but not simpler.-Alber Einstein

The two quotes embody a basic software design philosophy that, when applied, results in good things: simple code is clear, maintainable, reusable, and extendable. But as Einstein notes, simplicity is hard.

This is is why Test Driven Development (TDD) is beautiful. When practiced with discipline, automated tests guide the programmer to simplicty; they provide a roadmap to nirvana. (Alright, this is a bit too flowery. I am starting to sound like an XP evangelist)

Achieving simplicty is still hard. But for software, TDD makes it a little easier.

While a freshman in college, I took an introductory physics class where one of the professors, though a really nice person, insisted on using the adjective "obvious" to describe most concepts. Every now and then, something was "more or less clear" or "relatively straightforward". A few of my friends and I would ask each other if anyone understood any of the material presented, much less found it obvious. We were lost and relied on the explanations of our teaching assistant to help. (I must digress for a moment. David Bear, the teaching assistant in this story, is one of the most intelligent people and competent teachers I have ever met. He is amazing.)

We were so lost that we resorted to keeping tallies during lecture. One section of the audience would track the word "obvious", others would track the "more or less clears", etc. We finally asked David, the teaching assistant, if he thought any of it was obvious. He then told us this. "When you are dealing with Nobel Prize winners and the like, you learn something. If they say something is 'obvious', you think about it for a few minutes, might see the connection and then it is obvious. If they say something is 'more or less clear', you go home, maybe ask me; basically expend some real effort, see the connection and are okay. If they say 'relatively straightforward', then if, before you die, you have the vaguest notion as to what they were talking about, it was 'relatively clear'.?

Realizing that we were doomed, we started taking bets on the daily tallies for the expression counts. Then, during one lecture, a student raised his hand and asked the unthinkable. "Professor, can you explain the connection, as I can't see why it is obvious?" A hush literally fell over the crowd. The professor looks at the board, then back to the student, then back to the board then to the floor. Board, student, board, student. After a rather long pause, he looks up and says, "Is David here? Ah, David, perhaps you can help me. Can you explain to this student the connection, as I can't think of a way to explain it simply?"

David's response was, "Honestly professor, I haven't been able to follow anything you have been talking about and I definitely don't think it?s obvious."

The class stood up, turned around and gave David a standing ovation. After it subsided, the professor turned back to the board and said (quite simply and relaxed), "Well I suppose I should be more careful with my use of the term 'obvious'."

The lesson is pretty obvious. We should be careful about our assumptions. But I am amazed with myself, having been a victim of this experience, that I frequently make all kinds of assumptions and use the term "obvious". I may describe an idea without careful clarification. I observe many other people do the same.

It has been my experience, that the best "Aha..." moments, for an individual or team, occurs when the actual explanation for an idea, previously taken for granted, comes to light. Everyone learns something, perhaps about the assumptions being made, deeper insight or both.

For example, I was recently at Agile Fusion, an event where testers and XP developers explored the integration of testers into an XP project. A key "Aha" moment (so I thought) was when automated testing was described as "automated change detection". This seemed to more precisely convey one way developers use automated tests. It seemed to provide comfort to many of the testers, as they realized developers didn't intend for test suites to detect bugs. Some testers had thought (rightfully so), how could automated tests do the job of a skillful tester? This realization made it easier for us to work together.

I have started using the term "change detection" when describing automated testing. It has allowed me to "convert" a few developers to embrace (or at least really try) the technique. It has also been a good way to explain the value of it to management.

I have tried to erase the term "obvious" (and its related cohorts) from my vocabulary. I am not too successful, but my awareness has been raised. Its a good first step.

I have a lot of random ideas that spark my interest. Some of these are worth formulating and exploring; other are nothing more than a mental soundbite. I am trying to capture and record them, in the hope that I may either one day explore them or, in the process of writing about them, realize they aren't worth much attention.