launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Thu, Feb 11, 2010 at 5:02 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jonathan Lange wrote:
>> On Wed, Feb 10, 2010 at 11:49 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
>
>> As Martin put it, I meant this as a toolbox from which people can use
>> what fits the situation, not as a straight jacket, nor as a set of
>> hoops to jump through.
>
> You said "I'm proposing that before we begin work on _anything at all_,
> we run through this checklist: bugs, refactoring, features, whatever".
> You used emphatic language and underscores, so I took you literally.
>
> Because I thought "positively" in ReadyToCode meant "affirmatively", I
> thought that all questions had to be answered "yes".  That would be a
> set of hoops to jump through.
>
> Put those together, and you have a straitjacket.  If you didn't actually
> mean "anything at all", nor that all questions had to be answered
> affirmatively, I'm happy.
>

Cool.

>>> Jonathan Lange wrote:
...
>> What I'm saying is that we shouldn't _stop_ working on something until
>> it's really very good. I could point to specific examples of where we
>> have done this.
>
> I'm fully behind that sentiment, and I agree we've had problems like
> that.  What if we find cases where it's good and we don't know how to
> make it excellent?
>

Very glad you agree.

As for the case of something we don't know how to make excellent, I
don't know the answer. Do we need to have an answer now?

>>>> 1. https://dev.launchpad.net/ReadyToCode
>>>>
>>>> It's a very short list.
>>> Couldn't it also be seen as long?  It is actually eleven points, and
>>> many of them look like they would take more than a few minutes to complete.
>
> I would still like to see a response to this.
>

It could be seen as a long list. It is one item longer than God's most
famous list, for example. It's also at least two items longer than
seven plus or minus two. On the other hand, it's shorter than "The
Twelve Days of Christmas" and the D&D 3rd edition first level spell
list for wizards and sorcerers.

I don't think it would take more than a few minutes to complete for
cases that don't involve UI.

>>>> If you can answer every question on this list clearly, convincingly and positively, then you are ready to code.
>>> By "positively", do you mean affirmatively, not "with good spirits"?
>>>
>>
>> I think I meant a bit of both. I meant to guard against people
>> answering "Yes" or "No" without qualifying it. Perhaps a better word
>> would be "specific".
>
> Hmm, that's very different from the meaning I took.  I took it to mean
> "affirmatively", which would mean that "yes" answers would be required
> for every item on the list.  I think "convincingly" already covers most
> of what you mean, possibly something about justification would help.
>

Yeah, reading it now, I think what I really actually meant was "if you
say 'no', have something to balance it."

>> How can I make it clearer on the wiki page itself?
>
> Maybe something like "A rationale should be provided if the answer is
> no"?  And I think "positively" is too ambiguous to stand alone, so it
> should either be explained or removed.
>

Thanks. I've dropped this, and used your clarifying point (with some tweaks).

>>> Why does it make sense to generate a list of representative users /
>>> stakeholders for a trivial bugfix?  Why does it make sense to talk to
>>> them?  Do you mean vocal communication, or if not, which forms of
>>> communication do you mean?
>>>
>>
>> I would argue that the representative user for a trivial bug fix is
>> the person who filed the bug. I would argue further that it's good to
>> ask something of that person when you fix it. e.g. "I've fixed the
>> bug, can you give it a try?"
>
> It might be a good idea, but this process happens before you fix the
> bug, so I don't see how it's relevant.  Could you take another stab at
> answering this?  Especially the bit about forms of communication?
>

Forms of communication: ultimately, any. For features, I'd strongly
recommend vocal communication, and if possible face-to-face user
testing. For a bug fix, the bug report is probably enough.

IRC & email are great too.

>>>> What are the constraints on possible solutions?
>>> Why should we consider this for a trivial bugfix?  Isn't this likely to
>>> degenerate into justifying the obvious solution after the fact?
>>>
>>
>> To be honest, I've never tried, though I'd like to.
>
> So, here's one that's fresh in my mind: bug #492275.
>
> The fix is:
> @@ -581,8 +582,13 @@
>                 [message.get('from')],
>                 'Error Creating Merge Proposal', body)
>             return
> - -
> - -
> +        except BranchCreationException, e:
> +            body = get_error_message(
> +                    'branch-creation-exception.txt', reason=e)
> +            simple_sendmail('merge@xxxxxxxxxxxxxxxxxx',
> +                [message.get('from')],
> +                'Error Creating Merge Proposal', body)
> +            return
>         try:
>             bmp = source.addLandingTarget(submitter, target,
>                                           needs_review=True)
>
> Now, to me it seems obvious that we should handle this kind of error the
> way we handle other kinds of errors in the same situation.  I don't
> think that it makes much sense to revisit the constraints.  If pressed,
> I'd say the constraints are:
>
> - - we must explain why their merge proposal was not created
> - - we cannot do this using a web page, because the user will not
> necessarily be using our web site when this error is encountered
>
> Do you have any insight?
>

I'd add "we must provide the user with an avenue for further enquiry
or a way of resolving the problem", and would challenge the second
requirement, because we could also show the user the error when they
next log on. Which raises the question "what happens if they never log
on again?" and then you've had an interesting long discussion that
doesn't really help get the bug fixed but maybe shows you avenues for
fixing the whole category of these bugs in a better way.

Reflections / Thoughts:
  * For every bug fix, I agree, doing that would be foolish.
  * Not doing it for any bug fix at all, otoh, is also a mistake,
because it assumes the current norm is the optimum.
  * The check item is much more useful for features (reworking or
creating) than for correcting defects.
  * Many defects are solved by reworking features. (I'm thinking of
merge proposals here.)
  * Drawing the line between "too simple to need to think about
constraints" and "big enough to require thinking about constraints" is
hard, there might not even be a line.
  * Even if you figure it out, it'd be very difficult to phrase, read
and use as a decision making tool I'll bet.

So I guess I'm in favour of phrasing it strongly then trusting you to
break the rules when it makes sense and to follow them when you don't
really want to but think that it'll get a better result or help you
communicate outside the inner team or what have you.

>> If it's make-work, don't do it.
>>
>> More broadly, there are two ways you can think about trivial bug fixes
>> and this RtC list.
>>   1. ReadyToCode doesn't apply to trivial bugfixes
>>   2. A change is trivial if most of the ReadyToCode list doesn't apply.
>>
>> I'm thinking the second way and it sounds like you are inclined to the
>> first way. I don't think it matters much which way you approach it,
>> just as long as the list is used as a bunch of prompts to genuine
>> thought.
>
> Your initial email doesn't admit the possibility of 1; you said "I'm
> proposing that before we begin work on _anything at all_, we run through
> this checklist: bugs, refactoring, features, whatever".  You used
> emphatic language and underscores, so I took you literally.
>

It doesn't admit the possibility because I don't think you should do
it. Also, it makes the whole thing simpler, with fewer "if"
statements.

I admit the possibility now because having thought it through, I know
that the results will be indistinguishable for genuinely trivial bugs.
I strongly prefer 2. to 1., because that provides the opportunity to
question a bug's triviality, and works against non-trivial changes
disguising themselves as trivial changes in order to avoid, say,
having to listen to users.

> Because I thought "positively" meant "affirmatively", I didn't think
> that 2 was an option either.
>

A fair interpretation.

>>>> Have you talked to someone else about this?
>>> If I have talked to representative users / stakeholders about this, then
>>> I have spoken with someone else about this.  Isn't this redundant?
>>>
>>
>> In my head, I was thinking of two things:
>>  - another Launchpad hacker
>>  - it's really quite important to speak to someone else, so maybe put
>> it in twice
>
> I think specifying "another launchpad hacker" would make more sense.
> Maybe even "an experienced launchpad hacker"?
>

Good change. I'll leave off the 'experienced' for now.

>>>> I'm proposing that before we begin work on
>>>> _anything at all_, we run through this checklist: bugs, refactoring,
>>>> features, whatever.
>>> Why is this appropriate for bugs and refactorings?
>>>
>>
>> It's appropriate to think about why you are doing something,
>> regardless of whether it's a feature or a refactoring. I also think
>> there are some good things that should be done often (like UI mockups
>> & pre-implementation calls) and that it's worth making an explicit
>> decision *not* to use them, rather than forgetting to use them.
>
> I think that this requires changes to our programming culture, and while
> checklists and policies can contribute to that change, they cannot stand
> alone.  People need to believe that these things are worthwhile to them,
> or at best they will do them grudgingly.
>

Damn straight.

How can I help make this happen?

>>>> It might be a useful thing to use for
>>>> pre-implementation calls.
>>>>
>>>> 2. https://dev.launchpad.net/LaunchpadEnhancementProposalProcess
>>>>
>>>> If getting ready to code is actually non-trivial, then you might want
>>>> to use this to help get there. I've tried hard to keep it as simple as
>>>> possible.
>>> The "do not need to follow" list seems to overlap with the "definitely
>>> need to follow" list.  For example, I could be adding a new feature, yet
>>> have clear, convincing and positive answers to the checklist.  How
>>> should I resolve this apparent contradiction?
>>>
>>
>> Good question. I don't really know how to change those lists (which
>> are meant to help you decide instead of actually deciding for you),
>
> I recommend changing their descriptions, then:
> "You do not need to follow this process if" => "Factors suggesting you
> do not need to follow this process"
>
> "You definitely need to follow this process if" => "Factors suggesting
> you should follow this process"
>

I guess one of the sources of tension in this discussion is simply
that I prefer mild hyperbole to precision in process documents, all
things being equal.

I've not changed the headings, but I've added some qualifying text
that I hope helps.

>>>> The Product Strategist triggers this process and approves any output from it.
>>> Why can only the Product Strategist trigger this process?  Combined with
>>> the "you definitely need to follow this process" list, this seems to
>>> imply that the product strategist will decide which features to
>>> implement and rework, which workflows to extend or change.
>>>
>>
>> It's my understanding that it's actually my responsibility to do so.
>> Francis can correct me if I'm wrong.
>
> Do you think that this makes sense for a small feature or minor
> reworking of a feature?
>

Yes, for now. If we had something that showed the features, reworkings
and UI changes that we've made over the past six months as a timeline,
then I'd feel a lot more comfortable building in explicit exceptions
right now.

>> I should have communicated more about the role earlier and better.
>> These processes are part of an attempt to be more explicit, and also
>> to figure out the details.
>
> That doesn't seem to explain why only you can trigger the process.  As
> written, the documents state that a developer can determine that they
> need to follow the LEPP, but they cannot actually start the process.  It
> seems strange.
>

What it's trying to get at is that paid work on new features or on
revamping existing ones is driven by business needs and user needs,
and that if you start something of that scale, you need to check that
it aligns with them.

FWIW, I agree with Martin Pool when he says the ideal is that the
things developers want to work on are exactly the things that most
benefit the business, and managers needing to change developer
direction is a sign of management failure. Unfortunately, solving that
problem is beyond my abilities at present.

To me this is kind of tied to the next section, so maybe reply-below
style discussion isn't the most appropriate.

>>> How can it be reconciled with "have spent more than thirty minutes
>>> talking..."?  The only way I can reconcile it is "If you spend more than
>>> thirty minutes talking about a change, you must abandon it, until such
>>> time as the Product Strategist decides that should should implement it."
>>>
>>
>> Well, what were you going to do with it?
>
> Sorry, I don't understand the question.  Normally, I would continue to
> implement the feature.
>

I'm not sure that's correct. Often we talk of features and then do
nothing about them, because it's not the most important thing to be
doing at the time. Sometimes we talk about them and then do them,
because they are the most important. For paid work, "important" is
defined by business needs, and the Strategist position is largely
about identifying those needs.

So I guess I'm not sure what the problem is here. Or, I do see the
problem, but it's a really deep one that already exists and that this
process simply makes explicit.

>>>> In the process, I suggest that we use blueprints for keeping track of
>>>> these proposals. I think it's time we started eating our own dogfood
>>>> again.[2]
>>> Do you agree that the purpose of eating our own dogfood is so that we
>>> can improve it?  If the dogfood has already proven unpalatable and there
>>> has been no concerted effort to improve its flavour, shouldn't we
>>> improve the dogfood before attempting to eat it again?
>>>
>>
>> Maybe. Can you suggest a tastier alternative?
>
> Let's to a LEPP called "make blueprints awesome in a month".  When we're
> ready to code, we steal one team member from each team to make a virtual
> blueprints team, implement the LEPP, and start dogfooding.  But we
> should only dogfood if some people are given responsibility and
> opportunity to implement improvements.  Otherwise, it's just an exercise
> in futility and frustration.
>

Sounds very tempting :)

Even so, in the mean time we'd still need a place to list LEPs and
track their progress. I don't want the process to be blocked on that
and I dislike blueprints slightly less than I dislike editing tables
in moin.

>>> Speaking of dogfood, have you considered applying these proposals to
>>> themselves
>
>> I hadn't, and not all of them apply because it's not code, but here goes:
>
> This pretty useful, so that validates the checklist to me.
>

Glad to hear it. For what it's worth it only took a few minutes, and I
had phone calls and door knocks in between.

>
>>>> Create the blueprint
>>>> Create the wiki page
>>>> Talk to someone
>>>> Start adding constraints
>>>> Jot down sub-features
>>>> Identify workflows
>>>> Get it reviewed
>>> It seems plausible that all these activities would take longer than the
>>> time it takes to implement the feature, reducing the time available to
>>> do iterative improvement.  Is that an acceptable tradeoff?  If so, why?
>>>
>
> What do you think?  Am I wrong about the time this will take?  If I'm
> not, is it an acceptable tradeoff?
>

I don't think it will take longer than the time it takes to implement
the feature. If it takes that long, then it's probably not an
acceptable trade-off. Note that I'm thinking of "time to develop the
feature" as something more than just feature-complete or the first cut
of a feature.

It will take time though, and I think that the time it takes is an
acceptable trade-off.

>>> Are you sure that this is not big design up front?  What makes it different?
>
>> Because analysis and design are two different things. Being clear on
>> the problem is not at all the same as making decisions about the
>> solution.
>>
>> The UI mockup work is in there mostly because we're already required
>> to do it, it helps and having two separate things for it seemed
>> mechanically clunky (although conceptually cleaner).
>
> Analysis and design may be different, but from what I can tell, this
> process does both.  LEPP does insist that design be informed by
> analysis, and that's a good thing.  I still think it's all being done up
> front, though.
>

I'm saying that we should do some analysis up-front and some design
up-front. We already do this informally, I think, and should spend the
little extra time to write it down and share with others.

I hope this helps.

On a meta-note, this discussion has been very useful to me in
clarifying my thoughts and improving the docs, but gosh it's a big
discussion. I've spent a fair bit of time on my replies, and would be
happiest if the discussion (or even our opinions!) converged rapidly
after this one.

jml