TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
Date:
Tue, 20 Jun 2000 09:52:55 -0400
Reply-To:
"David J.A. Koogler" <[log in to unmask]>
Subject:
From:
"David J.A. Koogler" <[log in to unmask]>
Content-Transfer-Encoding:
7bit
Content-Type:
text/plain; charset=us-ascii
Organization:
Boolean Solutions, Ltd.
MIME-Version:
1.0
Parts/Attachments:
text/plain (36 lines)
[log in to unmask] wrote:
>
>>Slightly more seriously, I probably could generate 10kSLOC with
>>CBuild (the Claw application builder) in a 12 hour day. And that also
>>would all be working, readable, commented, Ada 95 source code. That
>>would make a good GUI for a Windows program. But actually writing the
>>application to do something after the menus were pulled down and the
>>dialogs popped up would take somewhat more time...
>
> Now this is getting silly. Surely we don't include generated code in
> the SLOC metric do we? Besides the rates of 10SLOC/Day are related to > the number of lines written, tested and documented aren't they?

If a tool amplifies the effectiveness of your programming staff by a
factor of 10 or 100, would you not like to demonstrate this improvement?
SLOC is a simple metric that most managers can understand so I would
show the tool's affect as an equivalent SLOC measure. In effect, the
tool replaces some number of programmers you would need to achieve the
same SLOC output.

As to the second issue about tested and documented code, I have more
faith in mechanical generation than hand generation. Once I can prove a
mechanical tool works and I understand its limits, I can depend upon it
and devote far less testing to its outputs than I would for the
equivalent hand generated code. For example, I tend to trust a compiler
more than an assembly language programmer. I have not seen too many
test plans that exercised the compiler but rather focused on the hand
generated code.

Likewise for documentation, many of the code generating tools start
from higher level expressions of intent. Many of these expressions are
usable as documentation and might be easier to read and less ambiguous
than prose descriptions.

David Koogler
Boolean Solutions, Ltd.

ATOM RSS1 RSS2