Productivity comparison (Was Re: Function point counting)
Stephan B. Wessels
swessels at one.net
Sun Apr 14 00:57:57 UTC 2002
Here's a scenario that is not uncommon with good smalltalk people.
The developer spends time browsing the source code, looking for similar
patterns to the feature that needs to be added. In the process the existing
code gets factored, cleaned up and quite often large parts of it get
deleted. The resulting code without the new feature ends up being easier to
understand and extend. Then the new feature gets added by minimal code
changes or additions in select places.
The net result is that the new feature is completed yet the overall count of
lines of code decreased and quite probably the overall quality and future
potential reuse increased.
I think I once heard Kent Beck say something like, "I kept factoring the
code down and simplifying until there wasn't any code left. That's how I
knew I was ready." It's a humorous thought but also bang on the money. I'm
very interested in working with developers who know how to complete
something by reducing how much exists first.
As far as I can recall we go through this kind of iteration with Squeak
every once in a great while...
Just a thought. :)
On 4/13/02 5:04 PM, "David Salamon" <david at myth.sdsu.edu> wrote:
> On 4/13/02 1:23 PM, "Ned Konz" <ned at bike-nomad.com> wrote:
>> My impression of function point analysis is that it's of most interest
>> to MIS types interested in scheduling "resources"  for big data
>> processing projects. I mean, really: count input files, output files,
>> etc... for most more modern project estimation I would think you'd be
>> more interested in "feature points", whose advocates claim are a
>> better metric of project complexity on non-standard-DP projects.
> It is actually the amount of code per feature point I am interested in, but
> this seemed to be covered mostly on function point web sites. I am mainly
> looking for an accurate productivity/clarity/quality comparison between
> I think the whole scheduling resources thing ultimately boils down to
> wasting as little time as possible, and to my eye, that¹s a good thing (As
> for how they peruse this goal...)
> David Salamon
More information about the Squeak-dev