Re: Strategy

On Sun, 2008-09-21 at 23:36 +1200, Amos Jeffries wrote:
> Alex Rousskov wrote:
>
> > * Look for simpler warts with localized impact. We have plenty of them
> > and your energy would be well spent there. If you have a choice, do not
> > try to improve something as fundamental and as critical as String.
> > Localized single-use code should receive a lot less scrutiny than
> > fundamental classes.
> >
>
> Agreed, but that said. If you kinkie, picking oe of the hard ones causes
> a thorough discussion, as String has, and comes up with a good API. That
> not just a step in the rght direction but a giant leap. And worth doing
> if you can spare the time (months in some cases).
> The follow on effects will be better and easier code in other areas
> depending on it.

Amos,

    I think the above work-long-enough-and-you-will-make-it analysis and
a few other related comments do not account for one important factor:
cost (and the limited resources this project has). Please compare the
following estimates (all numbers are very approximate, of course):

 Kinkie's time to draft a String class: 2 weeks
 Kinkie's time to fix the String class: 6 weeks
 Reviewers' time to find bugs and
  convince Kinkie that they are bugs: 2 weeks
 Total: 10 weeks

 Reviewer's time to write a String class: 3 weeks
 Total: 3 weeks

If you add to the above that one reviewer cannot review and work on
something else at the same time, the waste goes well above 200%.

Compare the above with a regular project that does not require writing
complex or fundamental classes (again, numbers are approximate):

Kinkie's time to complete a regular project: 1 week
Reviewer's time to complete a regular project: 1 week

If we want Squid code to continue to be a playground for half-finished
code and ideas, then we should abandon the review process. Let's just
commit everything that compiles and that the committer is happy with.

Otherwise, let's do our best to find a project for everyone, without
sacrificing the quality of the output or wasting resources. For example,
if a person wants String to implement his pet project, but cannot make a
good String, it may be possible to trade String implementation for a few
other pet projects that the person can do. This will not be smooth and
easy, but it is often doable because most of us share the goal of making
the best open source proxy.

> > * When assessing the impact of your changes, do not just compare the old
> > code with the one submitted for review. Consider how your classes stand
> > on their own and how they _will_ be used. Providing a poor but
> > easier-to-abuse interface is often a bad idea even if that interface is,
> > in some aspects, better than the old hard-to-use one.
> >
> >> Noone else is tackling the issues that I'm working on. Should they be
> >> left alone? Or should I aim for the "perfect" solution each time?
>
> Perfect varies, and will change. As the baseline 'worst' code in Squid
> improves. The perfect API this year may need changing later. Aim for the
> best you can find to do, and see if its good enough for inclusion.

Right. The problems come when it is not good enough, and you cannot fix
it on your own. I do not know how to avoid these ugly situations.

> for example, Alex had no issues with wordlist when it first came out.

This was my first review of the proposed class, but I doubt it would
have changed if I reviewed it earlier.

Thank you,

Alex.
Received on Sun Sep 21 2008 - 22:50:58 MDT