Unit test enables develop in baby steps thus improve the efficiency

Assumption:

Consider each line of code has apossibility of being error, which is 0.6%.

Assume that each line of code isindependent with other line of code.

Then, a feature of 1000 line of code will have an expected errors E(errorLine) = 1000*0.6% = 6, which we normally put in our release plan :)

 

Now, compare the differences exist in debug overhead between develop in baby step and the develop in 100 lines batch.

 

In 100 lines batch:

Possibility of having error code= 45.2%

Taking that we will need toreview all 100 lines if there is an error, the expected code to review is 100 *45.2% = 45.2

10 batches will make it 452 lineto review for debug purpose

 

In 1 line baby step:

Possibility of having error code= 0.6%

Expected code to review is 1 *0.6% = 0.006

1000 times will make it 6 linesof code to dig for error correction

This makes the debug overhead coding in 100 line basis is 75 times higher than if we coding in 1 line basis.

 

Unit Test enables baby step thus improve the efficiency:

1. only UT can provide feedback for single line of code modification

2. UT has very low cost to write and to run

3. UT is very quick: complete in no second, don't breaking the flow of coding

 

Argument: Unit Test needs extra effort to write

Response: written once, and protect code for regression purpose for 1000 times.

Yet, this explanation is far from perfect, cause the model of counting the debug overhead is imperfect

1. each line of code can not be independent

2. to fix all the bugs in a piece of code, it can not be enough just to read through it once, a better assumption is that it needs read more than one time depending on how many bugs in it. 

Say, we have 1000 line of code developed in one shot, and expected bug number is 6, given the possibility of each line being a error is 0.6%.

So we will need to go through the 1000 line 6 times, each time for a bug, that makes a total line to go through is 6000, instead 997, 1000 * 99.7% (99.7% is the possibility of the 1000 lines of code contains error) lines as can be predicated from our origin model

3. it's not count that finding bugs is more difficult within larger sized code. According to the book "The Principles of Product Development Flow", it could be 2^n times difference, which n stands for the line of code, as code interact. I have a doubt on this assumption, but still, I will have to agree that the more code we have, the more difficulties it is to debug.

All 3 imperfectness of the model will leads the result of the way of developing in bigger batch worse. Thus did not change our point that baby steps and UT benefit for efficiency.