Re: Strategy

On Mon, 2008-09-22 at 13:45 +1200, Amos Jeffries wrote:
> > 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
> >
>
> Which shows that if Kinkie wants to work on it, he is out 8 weeks, and the
> reviewers gain 1 week themselves. So I stand by, if he feels strongly
> enough to do it.

Yes, but only if we have enough reviewers that will spend that much time
on a painful, multiple-iteration, fight-for-every-point,
earn-yourself-enemies review without a guarantee of a payoff. Most folks
would rather right code, even if it takes a little longer.

> > 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.
>
> Then that trade needs to be discussed with the person before they start.
> I get the idea you are trying to manage this FOSS like you would a company
> project.

Not at all. A company assigns projects to employees. None of the
problems we discuss in this thread exist in a well run company (they are
replaced with different ones).

Here, the Project can only control the final step (the submission of the
code). Everything else is 100% voluntary and we can only provide
resources and suggest options. I wish we could find a way to minimize
situations where person's hopes are crashed at that last step and/or the
project resources are wasted during that step and/or bad code gets
committed because of the review bottleneck.

My "trade projects" comment above was addressed primarily at your remark
that you needed String but could not work on it. The trade I am talking
about is still 100% voluntary and there is no central authority
regulating it. The bottom line is that I would rather make a String in
exchange for a few projects on my list, than spend about the same time
reviewing String in exchange for ... a String!

BTW, implicit trading happens now as well, when each of us improves
Squid for the benefit of all. What I was proposing is no different, just
a little more explicit so that if somebody is waiting for Foo, they have
more options than waiting or doing it themselves...

Perhaps the word "trading" implies commercialism, but I did not mean it
that way. I should have said "exchange" or "help", I guess.

> >> 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.
>
> Teamwork. Which I thought we were starting to get in the String API after
> earlier attempts at solo by whoever wrote SquidString and myself on the
> BetterString mk1, mk2, mk3.

Teamwork requires a balance of responsibilities and trust. The String
project has not been a teamwork so far. It was Kinkie doing a lot of
hard coding work and then me spending obscene amounts of time fighting
with Kinkie over basic C++ principles. No balance, no trust.

> I doubt any of us could do a good job of something so deep without help.
> Even you needed Henrik to review and find issues with AsyncCalls, maybe
> others I don't know about before that.

External review is usually very helpful, of course. We all make
mistakes, and I probably made more than most.

BTW, Henrik's review of AsyncCall integration problems was indeed
extremely useful. Those discussions around comm_close API were a good
example of successful teamwork. I wish we had more of that!

Cheers,

Alex.
Received on Mon Sep 22 2008 - 03:19:21 MDT