Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #31523

Re: Return of the Applets?

Show key headers only | View raw

On 4/7/2015 11:51 AM, Martin Gregorie wrote:
> On Tue, 07 Apr 2015 10:45:54 -0400, Jerry Stuckle wrote:
> 
>> On 4/7/2015 9:29 AM, Martin Gregorie wrote:
>> Then what do you suggest as a better measurement?  Experts have tried to
>> come up with one for over 50 years, and haven't.
>>
> That depends on what you're measuring.
> 
> LOC is OK for measuring programmer productivity and for comparing sizes 
> of programs provided that they belong to related groups, e.g. block 
> structured languages. 
>

Which is the classical method for determining workload.

>> To do that, you need to define "Function Point Analysis" and how it
>> applies to each language.  And you need to define how much work is
>> required for each function point.
>>
> Sure, but function points are NOT language-specific: think of them as 
> atomic system functions that can be deduced from a requirements spec when 
> combined with the sort of high level ERD and numbers of display forms and 
> reports you'd use when costing a new project. At that point you can 
> estimate the number of function points (read a row, paint a screen, 
> validate input....) needed to implement each display form, etc. 
>  

No, function points are not language specific.  However, the amount of
work going into building a function point is quite language specific.

And when determining which language to use, function points is almost
never a consideration.  There are much more important things to consider
- like what you need to do.  For instance, if I need heavy arithmetic
processing, FORTRAN is virtually always the choice.  If I need many
digits of precision, COBOL rules.  And if it needs to be cross-platform,
Java is a great choice.

Another important consideration is the talent you have on board.  Even
if another language may otherwise be the best for a certain project, if
none of your programmers are familiar with the language, it's probably
not a good idea to use that language.

Function points aren't even a consideration.

>> And then you will find different languages have different workloads for
>> each function point.  This then takes you back to LOC to determine
>> workload.
>>
> Multiplying the function points by language-specific weightings gives a 
> programming cost estimate, but you don't do that until the requirement 
> set is specific and the programming language(s) has/have been selected.
>

As I said above - function points are not even a consideration when
picking a language.

>> It really makes no difference whether the system is being built for a
>> one-off event or not.  The system is being built.
>>
> Yes it does: if you're writing something to test the practicality and/or 
> the performance of a design approach or if you know that program is 
> needed for a one-off purpose then you little or no documentation apart 
> from the requirement spec. OTOH if the system is expected to be in use 
> and maintained for a decade, of its something that is highly configurable 
> (such as a commercial banking package) then it needs to be documented 
> well enough to make maintenance, modification and configuration changes 
> relatively simple and so that supporting it is easy to pick up. I still 
> have mental scars from installing/supporting/maintaining systems which 
> lacked decent documentation.
> 

Even a program to test the practicality and/or design approach needs
documentation.  And in the projects I've managed, each is documented
exactly the same way as the final project.  Why?  Because if it works,
chances are it will become part of the final project.  And if it doesn't
work, sometimes another set of eyes can spot weaknesses in the code.

Even test cases are fully documented.

>>> Function point counting would do better here if you add a documentation
>>> effort factor for each function point. This would be as equally valid
>>> for traditional module document writing as it is for a combined
>>> approach, e.g. via javadocs for Java or cdocs/oxygen for C.
>>>
>>>
>> Pretty difficult since not all languages support javadoc or similar.
>>
> You use the tools for languages that support them and reap the benefits 
> of having the module-level documentation in the source and hence more 
> likely to be maintained as the code changes.
> 
> Otherwise you have use traditional word processors etc to maintain 
> separate module level documentation and accept the almost inevitable 
> problems that arise if, as usually happens, the documentation isn't 
> updated.
> 

Part of any properly defined change process includes updating the
documentation - and code is not released until the documentation is updated.

> I suspect there are are more third party javadoc-like tools for other 
> languages than you may have run across, e.g. there are at least two such 
> tools for C that, like javadocs, extract documentation from the source 
> files and I've seen systems where the source version control system 
> stored the requirements, HLL system design, database schema, forms 
> designs and COBOL source and could (a) generate systems documentation and 
> (b) feed source to the schema generator, compilers, etc.
> 

Sure.  But the documentation should be much more than what javadocs and
similar tools generate.  Most programmers (especially Java programmers)
are quite skimpy on the doc they generate.

Full doc includes not only the method name, parameters and return type,
but any constraints on each of those parameters and the return value. It
also contains a description of the processing it does, other methods
this one calls, and other methods which call this one.

Very little of this shows up in java documentation.

>> And BTW - you can access serial ports from many different languages, and
>> TCP/IP from Fortran or COBOL.  You just need the right libraries.
>>
> Some of these languages, e.g. Fortran and COBOL, don't have these 
> features in their standard libraries (where they even have a standard 
> library). Sure, if they can call external functions you can write 
> extensions, in assembler if necessary, but that isn't part of the 
> language and so shouldn't appear in the language metrics: 
> 

Java can't call TCP/IP either, without native-OS libraries.  The only
difference is these libraries are supplied with the JVM.

> - if you bought a 3rd party library, you shouldn't count much more 
>   than the function calls (one statement per call) in the language
>   statistics
> 
> - if you wrote the extension, the design/implement/test stats for it 
>   should count against the stats for that language and again, the 
>   calling code inly gets to count the function calls. 
>

Which is the same with any language.

>> Actually, documentation is a part of development, and can be related to
>> LOC, even though it is not part of the measurement.  I've been doing it
>> for the last 25 years I've been managing projects.
>>
> Good! From my past experience I suspect you're one of the few that did.
> How did you gather documentation stats? 
> 
> In Java you might do something like:
> 
>    DLOT = (source_lines - LOC)/F
> 
> where DLOT is 'Documentation Lines Of Text', LOC is the statement count 
> and F is a fudge factor to reflect that comment lines are easier to write 
> and review than source statements are to write and test.
> 
> 

It's pretty simple.  As part of the documentation, programmers indicate
the number of LOC in the function/method.  We've always kept a running
total, and used that against our design metrics to see how close we are
to the estimated workload.

Source_lines is not a good metric; it isn't unusual to have a long
source line span multiple lines in the file.  And occasionally you'll
have more than one statement on the same line.  For instance:

if (i == 3) return 5;
else return 6;

Depending on how you write it, this could be two, three or four LOC.
How do you count it?  You can't do it with a simple line counter; you'd
need to parse the entire file with a language-sensitive parser to make a
determination.

BTW - I usually count it as 3 lines (the "else" is not required), but
that needs to be determined as part of the project documentation so
everyone is on the same page.  But that doc may say to include the
"else", even though it is not strictly required at this time, for
consistency.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 09:46 -0400
  Re: Return of the Applets? Jeff Higgins <jeff@invalid.invalid> - 2015-04-05 13:12 -0400
  Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 15:14 -0400
    Re: Return of the Applets? Arne Vajhøj <arne@vajhoej.dk> - 2015-04-05 16:41 -0400
      Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 16:54 -0400
        Re: Return of the Applets? Arne Vajhøj <arne@vajhoej.dk> - 2015-04-05 17:08 -0400
          Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 17:17 -0400
            Re: Return of the Applets? Arne Vajhøj <arne@vajhoej.dk> - 2015-04-05 17:30 -0400
              Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 17:42 -0400
                Re: Return of the Applets? Arne Vajhøj <arne@vajhoej.dk> - 2015-04-05 17:52 -0400
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 18:17 -0400
                Re: Return of the Applets? Luuk <luuk@invalid.lan> - 2015-04-06 11:26 +0200
    Re: Return of the Applets? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-04-06 13:23 -0500
      Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-06 15:09 -0400
        Re: Return of the Applets? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-04-06 17:33 -0500
          Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-06 17:44 -0400
            Re: Return of the Applets? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-04-06 19:10 -0500
              Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-06 20:03 -0400
                Re: Return of the Applets? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-04-06 21:36 -0500
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 09:11 -0400
            Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-06 23:25 +0000
              Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-06 19:59 -0400
                Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-07 13:29 +0000
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 10:45 -0400
                Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-07 15:51 +0000
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 13:16 -0400
                Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-07 20:22 +0000
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 17:03 -0400
                Re: Return of the Applets? Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2015-04-07 11:34 -0500
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 13:18 -0400
                Re: Return of the Applets? Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2015-04-07 12:40 -0500
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 17:06 -0400
                Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-07 20:28 +0000
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 17:11 -0400
                Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-07 23:00 +0000
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 19:25 -0400
  Re: Return of the Applets? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-04-06 13:09 -0500

csiph-web