James G. Sack (jim) wrote:
How much code can one write before starting to test?
Only the programmer can answer that question.
The answer is: However much occurs before they become annoyed at fixing
bugs.
This is an extension of human complexity management. A human will
expand the complexity to a comfort limit and then stop there. That
comfort limit is dependent upon ability and experience.
In EE scheduling I have a rule of thumb: "Two weeks per engineer per
schematic". This is derived from data across many of the companies I
have worked and holds pretty constant.
What doesn't hold constant is the engineer and complexity of the task.
The better engineers wind up with the tougher tasks. So, even though
they are better, their assignments increase in complexity until the rule
holds. Less experienced engineers wind up with easier tasks but are
less comfortable so they produce less dense schematics that do less.
However, 2 weeks seems to be about where they wind up as well.
Part of that is also the fact that the schematics have to be
*communicated* in reviews. A too complex schematic won't pass review
because others can't understand it.
This is an expression of "psychology/sociology" rather than technical
aptitude. 2 weeks seems to be the "comfort" complexity level of
engineers drawing schematics.
Even in those cases, when undertaking future modification of the code
(evolution, bugfixes), even the original coder might well choose to
build some unit tests, at least around the internal parts that need
changing, before changing anything. You might say that the unit tests
get deferred until they provide specific refactoring benefits.
Bingo.
On the other end of the scale, I might find myself in some project where
I have no great past experience or intimate domain knowledge to call
upon. It would be nice to bring in reinforcements, but it's not always
possible. Sometimes the design itself is a fits-and-starts process
because the requirements are uncertain. Anyway, my point is that I might
proceed in fairly small steps -- code-a-little, test-a-little,
talk-a-little (with customers, colleagues, domain experts). Writing the
tests helps me understand the requirements! Associating tests and
requirements also gives me something concrete to base ongoing refinement
of the requirements. Witnessing or discussing the tests can even help
the customer verbalize and zoom in on what he wants.
Absolutely. In this case, the complexity is already well past your
comfort limit and you are using the test cases to bring it down under it.
Oh well, I'm rambling. But the point is that smaller bites may be
appropriate for some people, in some cases. .. it depends.
Ayup. There is no hard rule on this.
There is another general benefit of unit testing that I like to pitch,
but I'm having a hard time expressing myself. My observation of my own
coding practice is that I have started thinking about design and code
structure a little differently. Asking myself "how would I test that",
or "what does this do that I can test" leads me, I believe, to better
data structures, functions, objects, modular strength -- all those good
things. Well, it's not a magic potion, but I'm convinced that thinking
about testing makes my code come out smelling better.
Oooo. But then you are engaging in up-front design and the "test first"
folks don't like that either. <grin>
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
