Tuesday, November 10, 2009

TDD and Science



"The Goal" has influenced my life, the way I think & act.
However I think what's even more valuable than the book itself is the preface written by the author; where he has expressed his views on Science and Education. It's just a two page preface; that gave me some interesting line of thinking.

 
What is Science?
Is it about "solving the mystries of the universe" or "knowing the facts"?
No, science is about "postulate a minimum set of assumptions that through logical deduction explains the things happening around us".



This is a groundbreaking definition... it frees Science from being locked in fixed categories like Phisics, Chemistry, Biology. There is a science exists beyond it ... that explains how humans think, how organizations behave etc.


TDD (Test Driven Development) is just an application of above definition to the world of "Software Developement".
Are you wondering how? Let me take a real example.


There is something that has fascinated mankind from beginning of the life ... that's light.
Can we tell "What is the Light ?"
Do we "know" what light is? Perhaps the answer is "Not sure"... even today.
What we have is a theory which has got evolved over last many decades.


After all what is "Theory"?  Let's put Dr. Goldratt's definition explicitly.
A minimum set of assumptions; that through straight forward logical deductions; explains things happening in the universe.
So let's put down the observation or behaviour of light and try to make a theory according to above definition:
------------------------------------------------------------------------
BEHAVIOR #1 : When light falls on an opaque object; it gets reflected.
------------------------------------------------------------------------

Now let's see if our theory can explains this.
No it cannot. Because the theory is empty. We haven't written any code yet.


So let's put a minimum code that is just enough (yes just enough) to explain the observed behavior:


-------------------- Theory of Light --------------------------------
ASSUMPTION :
  • Light is made up of tiny particles called "Corpuscles".
  • These corpuscles are emitted from the source in all direction.
LOGICAL DEDUCTION:
  • When any particle hit an opaque surface it gets rebounded according to some law ---- [Fact]
-------------------- Theory of Light --------------------------------


Wow! the behavior is explained! The test has passed!
(I'm sure you have started noting the parallels)


Can we prove this? Yea....h..no.; not sure.
Can we disprove this theory?  Yes quite easy; just write another test that makes this code fail.
------------------------------------------------------------------------ 
BEHAVIOR #2 : When light enters from one medium to another medium its path gets deflected.
Phenomenon of Refraction.
------------------------------------------------------------------------


Can our theory explain this?
        No. So, the test fails.
Let's write some code that is just enough to make this pass.
Is it ok we write any "crap code" as long as the test is passed?
         No, remember the definition. We have to make a minimum set of assumptions or sensible assumptions and then it should be left to logical deduction to explain the behavior.


-------------------- Theory of Light (Revisited)--------------------------------

 ASSUMPTION :
  • Light is made up of tiny particles called "Corpuscles".
  • These corpuscles are emitted from the source in all direction.
  • Light being a particle is affected by gravity.
LOGICAL DEDUCTION:
  • Denser medium has more material per unit volume. Hence it can exert more gravitational force ---- [Fact]
  • When light particles enter a denser medium they are pulled by the gravity. Hence their path gets deflected.
-------------------- Theory of Light (Revisited)--------------------------------
Cheers! The test is passed.


But a word of caution: Our set of assumptions are increasing now. Like our code is getting into more if's and  then's. It's getting somewhat complex.


I'm skipping here.
Reason #1 : I need to go faster since I want to make some point.
Reason #2 : I'm not a physicist and I don't want to showcase my ignorance about these theories :-)


Let's assume that we go on explaining everything by adding more assumptions to our theory. Our code has got more and more complex. Also some assumptions we made were found to be incorrect.


-------------------- Theory of Light (Revisited)--------------------------------
ASSUMPTION:
  • Light consists of Waves.
LOGICAL DEDUCTION:
  • I'll leave it to you :-)
-------------------- Theory of Light (Revisited)--------------------------------


Did you realize what we have done?  Yes; its most important step in software development : Refactor the code!
When we are doing TDD; we don't fear to refactor. We are protected by Tests! We can ruthlessly throw away many lines of code that we wrote & cherished for a long.


Now let this theory evolve.
------------------------------------------------------------------------

 BEHAVIOR #3 : Light can travel through SPACE
------------------------------------------------------------------------


Now the Wave Theory fails. At that time "Electromagnetic waves" were not known and it was believed that wave requires a medium to propgate.


-------------------- Theory of Light (Revisited)--------------------------------

 ASSUMPTION:
  • Light consists of Waves.
  • Space is filled up with a medium called "luminiferrous ether".
  • This ether is having infinitely small density.
LOGICAL DEDUCTION:
  • It's obvious.
-------------------- Theory of Light (Revisited)--------------------------------



And so on...


I'll stop here. I'm talking on something on which I don't have authority to talk. I'll greatly appreciate if someone brings to my notice the technical mistakes (if any) I have made.


The point is ... TDD & Science are exactly the same. Not similar; it's the same.
TDD is one of the most scientific ways to develope software.


NOTE: I came across a book called "A Quest for The Theory of Everything" by "Stephen Hawkings"; where the author makes the same definition for Science.


There are many objections made against TDD:
-------------------------------------------------------------
  • In TDD everything is all well; as long as the tests are passed.
One can also write some crap code; break design principles; abuse OO etc. This threatens extensibility of the software in long run.
  • Tests overspecify the behavior.
  • Tests are unmaintainable.
-------------------------------------------------------------


I hope above approach answer above objections well.


TDD is not replacement for Architecture. It's not replacement for Code Review. Uncle Bob has explained extremely well on one of his recent posts on blog: http://blog.objectmentor.com/articles/2009/10/08/tdd-triage


We still need all these things.
Note the definition of theory says "It should make a minimum set of assumptions, or make only sensible assumptions". We just can't write any code just to make tests pass!


Then what's the advantage the TDD gives?
In my opinion, the biggest advantage is; it lets the programmer to get creative.


When a programmer gets creative?
 ... when he gets aggressive.
When he can get aggressive?
... when he can focus on the job or algorithm on hand... rather than worrying about broken code or regressions.
If you start with constraints; then there are fair chances you miss a good solution.
When this can happen?
... when your code is protected by Tests ... The tests that give you immediate feedback of what you are doing.


Do you find this interesting? Pl let me know.


Also pl visit following links to read more where TDD makes sense even beyond the world of Software Development.


1 comment:

  1. Excelent post! I found this approach really interesting.

    Like in science, when you program you must find a creative solution to a problem, and hence you must investigate and do some trial-and-error.

    TDD not only gives you immediate feedback of what you are doing, but it also guarantees that this trial-and-error won't be chaotic, and that your efforts will be directed at the right place.

    It makes your code more coherent, just like the scientific method.

    ReplyDelete