Re: Strategy

On Mon, Sep 22, 2008 at 5:19 AM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> 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.

I hadn't realized that reviewing my code took so much effort on
everyone's part, and I'm sorry for this.
BTW: no enemies, and the protracted discussion is IMO driven by
different viewpoints over what the final outcome should look like.
Which only makes the eventual outcome richer.

>> > 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!

From my point of view, String has the advantage of having (almost) no
external dependencies, which makes writing it easier.
If you want to take over, you can do it at any time (I'd suggest after
3.1 has branched in any case, but it's your call).

> 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 don't agree. We have different viewpoints, and we discuss over them.
We didn't fight, we brought arguments.
I'm sorry if it sounded different.
There can be no balance, for the reason that I write the code and you
have the power to veto it. That makes the relationship inherently
asymmetric.
I _do_ trust you though, although it doesn't mean that I'll just take
your word at face value if I believe have arguments to bring to the
table.
Our viewpoints _will_ converge - and in quite a few cases it's already
happened, even if it was more expensive than it could have been. In
some cases they will not, and that's OK for me too.

>> 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.

The only person who doesn't make mistakes is the one who doesn't do
anything at all (but it may be arguable that doing nothing is a
mistake, too).

> 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!

We will :-)

-- 
 /kinkie