launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

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

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

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

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

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

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

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

> Do you have a list of the UI workflows for the feature? 

How does this apply to a trivial bugfix?

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

- 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?  Will this process give users what they need even if it's
not what they want?

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

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

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?

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

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

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?

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

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

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktzRhkACgkQ0F+nu1YWqI3n2ACdGGUEJ4WeXPP9u2/Vr4RepykE
ZCkAoIDhL4shWqn25ng9qnS6LPy0RieT
=DXqa
-----END PGP SIGNATURE-----