Re: hosers-talk: too tired to keep working

[Jeff Schroeder <jeffs@xxxxxxxxxxx>]

At 01:06 PM 8/24/2001, you wrote:
> Quoth "Jon Stewart":
> > so, musing...
> >
> > Let's make some wild generalizations. All programming code is composed of
> > chunks which we call functions. Functions can all other functions;
> > functions can call themselves. All functions have a property known as an
> > interface. All functions exist as nodes in a directed graph (possibly with
> > cycles). The interface property determines if one function is connected to
> > another function; since it's a directed graph, this connectedness can be
> > non-existent, one-way, or bi-directional. The functions a particular
> > function is connected to determines which functions this particular
> > function can utilize.
> >
> > Suppose that every function in the graph is connected to some other
> > function; ie. the graph is fully-connected (ie. I forget the real term, if
> > unless the term happens to be "connected"; I'm tired). This is a peculiar,
> > inherent property of the graph. It simply doesn't make sense to add a
> > node to the graph which isn't connected.
> >
> > All functions have roughly constant utility.
> >
> > Total utility is equal to the particulary utility of a function times its
> > connections, summed over every function.
> >
> > Thus in any system, adding an arbitrary function adds at least constant
> > utility. As the number of functions increases, we have a linear lower
> > bound on utility.
> >
> > Even better, if we are good at designing interfaces, or lucky that our
> > systems seemingly choose fortunate interfaces for themselves, then adding
> > a function might bring about an increase in utility expressed in terms of
> > the number of functions in the graph. If this is the case, we can achieve
> > exponential growth in utility with linear growth in the added number of
> > functions.
> >
> > Why, then, does it seem that we so often get sub-linear growth in utility
> > as the size of our software systems increase?
> >
> > Possible reasons:
> >
> > 1. Poor interfaces, ill-suited to connectedness.
> >
> > 2. Functions vary wildly in their utility.
> >
> > Any others?
>
> Some functions may have conditional utility, unless you're doing some sort
> of 'objective' sum-over-all-users utility.
>
> Some functions may have negative utility, e.g., if they're broken or
> useless.
>
> I can add as many of these as I want:
>
> void foo(void) { ; }
>
> And I'd say the upper bound on their utility is 0.

One of my tasks is writing software, and probably the biggest problem I 
have noticed is the difficulty in documenting and sorting through the 
various functions already written.  In a large software project several 
functions there are various reasons for waste.  SumOfAB may perform the 
same (or very similar) function as SumOfBA, but written by different people 
for a different project for a different situation.  Another function might 
do almost everything you want it to do, but is lacking some vital 
component.  In that case it might be easier to rewrite a function that 
works only for you.  Changing previously written functions that suck can be 
futile depending on the size of the project.

If an awesome effort was put into keeping track of every function and their 
use, and if there is some way to generalize each function so that everyone 
can use it, then more problems arise.  The software can become so inter 
dependant with other functions, that changing anything becomes a nightmare, 
especially when you have a team of coders.

There have been entire books written on this subject!

jeff