[PRL] Code's Worst Enemy

Joe Marshall jmarshall at alum.mit.edu
Wed Jan 2 13:17:10 EST 2008


On Dec 29, 2007 11:25 AM, William D Clinger <will at ccs.neu.edu> wrote:
> Matthias wrote:
> > And the entire system actually rests on the gluing
> > together of N separate existing libraries (lib scheme,
> > wx:windows, and a slew of others initially and over
> > the years more joined).
>
> Mitch wrote:
> > So, what can we do about this?  If this is a (the?) Big Problem, shouldn't
> > we be working on it?
>
> Yes.
>
> Matthias wrote:
> > I consider it a real problem but not a 'grand challenge' type
> > question.

I think it might be one in disguise.  (Well, maybe not `grand', but
certainly `worthy of funding'.)

> Riccardo wrote:
>> But the message I got was that any project that starts
>> small and grows over the course of ten years to hundreds
>> of thousand lines of code will almost inevitably be a
>> mess, irrespectively of the language.

You say `almost inevitably'.  Are there counter-examples?

Although there are a lot of opinions on why code bloat happens,
is there *evidence* to show what is going on?

Matthias suggests:
>with very few exceptions,
>re-factoring is not something you can publish about and
>yet it requires a huge effort. We can't just afford it
>all.

This suggests that it is simply a problem of economics:
incremental simplification has less immediate value than
incremental complexification.  It sounds plausible, but is
it testable?  A solution seems obvious:  increase the value
of simplification and/or decrease the value of complexification.
Has no one ever done this?  (Is it not doable?)

Are there even metrics for these quantities?

I think the problem might be far more interesting and difficult
than it first appears.

Just my opinion.

-- 
~jrm



More information about the PRL mailing list