Home > Archive > Software Engineering > May 2006 > How to Benefits of Test Driven Development
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to Benefits of Test Driven Development
|
|
| martinus 2006-05-11, 8:01 am |
| Hi all,
At the company I work with I would like to introduce test driven
development. Although all of the about 30 people develop software in
one way or the other, most of them are mathematicians and therefore do
not have a strong software engineering background.
The big problem I face is that everybody believes that the increased
quality you get by using unit tests is not worth the effort. They don't
believe me when I tell them that in the long run they will be faster,
because their base code will be much more reliable.
So, I need some ideas how to get the people to use these unit tests! I
cannot force them, but somehow they should come to the conclusion that
Unit tests would really help.
Martin
| |
|
| martinus wrote:
> At the company I work with I would like to introduce test driven
> development. Although all of the about 30 people develop software in
> one way or the other, most of them are mathematicians and therefore do
> not have a strong software engineering background.
>
> The big problem I face is that everybody believes that the increased
> quality you get by using unit tests is not worth the effort. They don't
> believe me when I tell them that in the long run they will be faster,
> because their base code will be much more reliable.
How much time do they spend debugging?
Really - the extra quality is just a perk. The time spent using a debugger
will go way down. The time spent in punative debugging - with no recourse to
find the source of a bug - will go way down.
I worked for 2 years on a hard math project, using a soft language (Python),
without ever using the debugger.
--
Phlip
[url]http://c2.com/cgi/wiki?Z Land[/url] <-- NOT a blog!!!
| |
| Paul E. Black 2006-05-11, 7:02 pm |
| On Thursday 11 May 2006 08:53, martinus wrote:
> At the company I work with I would like to introduce test driven
> development. Although all of the about 30 people develop software
> ... most of them are mathematicians ...
>
> ... everybody believes that the increased
> quality you get by using unit tests is not worth the effort. ...
Some thoughts:
(A) Get one "convert": Find one person that needs help. Do a kinda'
pair programming where you write (or help write) the unit tests, which
he (or she) uses. Just the experience of thinking about test cases
and what and how to test may be enough. Later on when changes come
in, that person should find the unit tests valuable ...
(B) Ask them if they would start fiddling with equations without
knowing what the properties of the solution would be. Why start
writing code without knowing how to decide if the code works?
(C) Assuming there is no unit testing, who does system testing?
Propose that they scowl upon anyone whose code has a simple bug that
could have been caught with unit testing.
-paul-
--
Paul E. Black (p.black@acm.org)
| |
| H. S. Lahman 2006-05-11, 7:02 pm |
| Responding to Martinus...
> At the company I work with I would like to introduce test driven
> development. Although all of the about 30 people develop software in
> one way or the other, most of them are mathematicians and therefore do
> not have a strong software engineering background.
>
> The big problem I face is that everybody believes that the increased
> quality you get by using unit tests is not worth the effort. They don't
> believe me when I tell them that in the long run they will be faster,
> because their base code will be much more reliable.
Try a bit of math on them. The number of unique execution paths through
even a modest sized application will be measured in multi-digit
factorials. Ask them what they think the probability is they will get
every path right. Select some number for the total paths (e.g., 150!)
that they will buy as plausible. Then point out that even if they get
95% of the paths right the first time that they will still have a very
large number of problems to diagnose and repair. Let them guess at the
time to diagnose and repair a single problem. Then compute the total
time they will have to spend in diagnosis and rework after system test.
Next, point out that unit testing is a standard technique for managing
complexity. It is much easier to diagnose a problem when the scope of
change is limited and interactions between different problems are
reduced. Similarly, it is much easier to do repairs as-you-go before
the code gets too complicated. Use any plausible fraction that they
will buy for the improvement in diagnosis and rework time to compute the
savings from the total time above. No matter how conservative they want
to be, the difference will be large.
The next step is to point out that for any complex application it is
amazing to achieve even 30% path coverage in system testing. To do that
would require huge amounts of testing that would probably take longer to
create and execute than the product life cycle. So even with very
careful code writing there are going to be an awful lot of defects that
escape system test into the field. If they don't want to end up looking
like utter incompetents they better have something more than just system
test to determine product reliability.
The answer is to provide as many test screens as possible. That
includes things like work product reviews, unit tests, and subsystem
tests. It is well established that even when test screens have very
similar fault coverage, the value of multiple screens is
disproportionately high. So the more testing one does using different
techniques, etc. the better the reliability. And the sooner one does it
in the development cycle, the less rework is likely to be required. [It
is also well established that the total cost of fixing defects increases
drastically from one development stage to the next. Similar models
apply to IID where stages represent cumulative additions to the code base.]
In the end, though, probably your best bet with math types is to expose
them to the literature on defect modeling. Some useful references:
Successful Software Process Improvement. Bob Grady. Lot's of empirical
data here. Grady was a pioneer of SQA at HP.
Metrics and Models in Software Quality Engineering. Stephen Kan. Math
majors will love this. He has models and data for most of the
assertions I made above.
Applied Software Measurement Capers Jones. A classic. Jones runs one
of the largest databases on software development so there is plenty of
empirical data here.
Return on Software. Steve Tockey. This isn't directly related to your
problem but it may be useful for quantifying arguments in terms of
cost/benefit.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
|
| H. S. Lahman wrote:
> Try a bit of math on them.
Nice! But...
The problem with this approach is mathematicians are typically very smart,
and therefor capable of writing incredibly complex and utterly test-proof
code. So if that is their comfort zone...
Rigor is an illusion! Mathematics is a democracy!!!
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Pierre Asselin 2006-05-11, 10:00 pm |
| martinus <martin.ankerl@gmail.com> wrote:
> At the company I work with I would like to introduce test driven
> development. Although all of the about 30 people develop software in
> one way or the other, most of them are mathematicians and therefore do
> not have a strong software engineering background.
"one way or the other" ? Probably you should focus on the ones
who spend the majority of their time writing software. If software
is just a sideline they are less likely to benefit or listen to you.
> [ ... ] They don't
> believe me when I tell them that in the long run they will be faster,
> because their base code will be much more reliable.
In my experience the tests pay for themselves in less than a w.
You only have to keep the pressure for about that long. Warn them
up front that they will be writing as much testing code as payload,
that they will find tons of little bugs in the test code, and that
it's all normal. Sooner rather than later the tests will catch a
bug in the real code. That will happen more and more as they make
changes; then they will see the light.
> So, I need some ideas how to get the people to use these unit tests! I
> cannot force them, but somehow they should come to the conclusion that
> Unit tests would really help.
Choose your targets carefully ? If you turn one or two of them
that might be enough to start a tide.
--
pa at panix dot com
| |
| Ron Jeffries 2006-05-11, 10:00 pm |
| On 11 May 2006 05:53:53 -0700, "martinus" <martin.ankerl@gmail.com> wrote:
>At the company I work with I would like to introduce test driven
>development.
What good things would happen to you if you got to introduce TDD?
What good things would happen to the company?
What good things would happen to the other programmers?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
|
|
|
|
|