launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Wed, Feb 10, 2010 at 11:49 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
...
>

First up, thanks for the thoughtful reply. It has been helpful for me
to think about this from a perspective that demands logical and
mechanical rigour.

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.

Some of your specific points have made me think more broadly. I've put
those broader thoughts in with the answers to the specific questions.

> Jonathan Lange wrote:
>> Ultimately, it's not going to happen unless we all refuse to make
>> anything short of excellent.
>
> Are you sure that this is true?  Can't we start by making something
> useful, then make it good, then make it excellent?  Can we be sure that
> something is excellent before we even start coding on it?
>

Of course we can start by making something useful, then good, then
excellent. I hope I never implied otherwise.

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.

>> However, maybe some structure can help.
>
> Couldn't structure actually be a hindrance?  I am already finding that
> it takes me all day to make a trivial bugfix.  Wouldn't improving our
> velocity give us a better chance to polish things into excellence?
>

Yes, improving our velocity would give us a better chance to do that.
I don't think this will reduce velocity, and I don't have the coding
time to do the things I want that will actually increase our velocity.

Why don't I think it will reduce velocity? Because I think we mostly
already do think and talk about these things, and because I hope that
it will cut down time spent working on things no one needs.

>> 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.
>
> - From the document:
>
>> 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".

For example, for "Do you have mockups?" it is entirely valid to answer
"no". One should say, "No we don't need them because this is a
refactoring" rather than "no" and thinking "I can't be bothered" or "I
don't need no stinking mockups".

Does that clarify what I meant? How can I make it clearer on the wiki
page itself?

> This seems to imply that if you can't answer every question on the list
> clearly, convincingly and positively, you are not ready to code and
> should not code.  Is that your intention?  (It's not phrased as an
> equivalence, so I could come along and say "If Francis says you're ready
> to code, you're ready to code", and that would not contradict you.)
>

That is my intention.

>> What value this will bring to our users?
>
> How can this question be answered clearly, positively and convincingly
> for a refactoring?  On the face of it, a refactoring brings no direct
> value to users.
>

Two ways.

You could say, "it brings no value to our users", or you could change
"users" to mean "other developers".

>> Do you have a list of representative users / stakeholders? Have you talked to them?
>
> 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?"

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

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.

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

>> Do you have a list of the UI workflows for the feature?
>
> How does this apply to a trivial bugfix?
>

"There are no changed workflows"

>> Do you have mockups for these workflows?
>
> How does this apply to a trivial bugfix?  Would the lack of a UI mockup
> for a trivial bugfix mean that it could not be performed because it was
> not ready to code?  If the UI mockup is not required, what do you mean
> by "positively"?
>

I've tried to clarify what I meant by "positively" earlier in the email.

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

>> 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),
but I can help you resolve that particular contradiction.

When is it ever useful to write something down that you already know?
There are probably a lot of reasons, but I can think of two standout
ones: to communicate with others that you cannot speak to; to have
something that can be reviewed later.

Is the thing going to take a couple of days for you to write, land and
QA? I guess it's not worth bothering then. Is it going to take a
month? Well, then it's probably worth having something written down,
because people other than you are going to be talking about it.

> - From the document:
>> Launchpad regularly develops new features. We'd like to make sure
>> that these features are implemented well, and that they are what our
>> users actually want.
>
> Do you think excellent applications give users what they want, or what
> they need?  Or do they give them what they didn't even realize they
> wanted/needed?

What they need. Page amended.

>  Will this process give users what they need even if it's
> not what they want?
>

Not by itself, no. However, intelligent developers talking and
thinking in terms of requirements rather than implementation will
certainly help a lot.

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

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.

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

> If the Product Strategist will indeed become central to feature design
> and implementation, will they be able to complete all this work in a
> timely manner?  Will the process be problematic for those in opposite
> time zones, such as New Zealand?
>

Now *that* I don't know. I'm certainly aware of the dangers.

>> The author of any of the outputs... will normally be the Product Strategist or a Team Lead.
>
> Why shouldn't Launchpad developers normally design the features they
> will implement?
>

When I wrote that bit I was thinking of the big-arse things we
discussed at the TL meeting in September (build from branch etc). But
even then, it's not appropriate.

Changed to be broader.

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

> Speaking of dogfood, have you considered applying these proposals to
> themselves?  Can you answer all the checklist questions clearly,
> positively and convincingly?  Is "make our features so good that we have
> annoying fanboys queueing outside our retail outlets on release day" a
> contraint?  If so, is it a motherhood statement?
>

I hadn't, and not all of them apply because it's not code, but here goes:

 * What is it?

 A process for being clear on what our features are aiming for and
when they are done.

 * Why you are doing this now?

We are beginning to dismantle our major six-month / yearly planning
cycles and try to plan features closer to actual implementation. We
don't want to abandon planning altogether.

The ulterior motive is to bring more routine into the Strategist's role.

 * Who is this for?
   * Launchpad developers
   * The product strategist
   * Keen users who wish to have input in feature development

 * What value this will bring to our users?
   * Greater chance of features providing for users needs through
increased emphasis on user contact
   * More
   * Fewer bugs in features due to having ''some'' plan for QA

 * Do you have a list of representative users / stakeholders? Have you
talked to them?
   * Launchpad developers, doing so now
   * Francis, check

 * What are the constraints on possible solutions?
   * Absolutely cannot be a burden to developers
   * No BDUF

 * Have you talked to someone else about this?
   * Francis
   * Team leads

 * Do you have a list of the UI workflows for the feature?
   * There's no UI change. If it's worthwhile, I can come up with
workflows based on the existing UI & wiki.

 * Do you have mockups for these workflows?
   * No, since there are no changes to existing UI.

 * How will you know when you're done?
   * When the docs are written and have been used for at least one
feature from planning through to QA & signoff.

 * How will you know how well you did it?
   * Developer feedback (vague)
   * Improved user satisfaction (vague)
   * Possibly, fewer bugs filed post-feature delivery.

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



>> Finally, I said this earlier in an email with smaller circulation, but
>> it bears repeating:
>>
>> I really, really believe that big design up front is a wasteful
>> practice that produces crappy software and unhappy developers.
>
> 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).

>> With that in mind, I want to know your thoughts on the whole thing.
>
> I think there's a risk that we would avoid reworking features and
> working on silly features by not working on features at all.
>

I do not believe that anything I've proposed will cause that to happen.

Thanks again for the considered feedback.

jml