launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 13 February 2010 01:45, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:

>> 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?
>
> It depends how strongly you feel about refusing to do anything that
> isn't excellent.

I'd change it from "refuse" to "Don't be satisfied with anything less
than excellence.  Be impatient to get there."

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

What has worked for us in Bazaar is:

1. identify problem patterns, with vivid and painful real examples
2. get agreement that those patterns are indeed something the team
deeply desires to avoid in the future
3. propose an alternative process that might avoid the problem;
discuss until something is found that is cheap to try and might fix it
4. go and try it, knowing that this process is not a burden imposed by
the mgmt but rather something that may make development more fun

Clearly jml has problems he wants to fix but it could help to make
them more explicit.  In his first mail and documents he proposes

> * avoid reworking features

I think this needs to be unpacked a bit more; there's nothing
necessarily wrong with an evolutionary approach.  Is there an example
of rework that was clearly wasteful and avoidable?

> * avoid working on silly features

Obviously jml thinks this is a problem, but I've never personally
looked at a Launchpad feature and thought "that's just silly," so I'd
like an example.

> * make our features so good that we have annoying fanboys queueing outside our retail outlets on release day

This is a much more inspiring statement, and I'm sorry I only want to
talk in terms of problems.  Yet to me they seem easier to analyze.

I think the problem here is that Launchpad so rarely polishes a
feature from being "done" to being "amazing."  A case in point would
be "affectsmetoo", which seems so useful, but also feels like it's
been left half done in favour of adding another similar feature, "bug
heat".

I don't mean by raising that example any personal criticism of the
bugs team (who have done great work) and I do recognize the situation
is complicated.  Yet it does seem like a case where Launchpad has not
excelled quite so much.

> * crappy pain points in the user interface

This does seem to happen; it can take the gloss off new features.

> * feature definitions that can inform qa
> * don't get user input at the requirements stage

Do Launchpad developers feel these are major problems?

some that seem implicit

* people don't talk to the product strategist / architect before
starting implementation, and as a result.... what?
* people implement features without talking to anyone else at all,
neither developers nor users?
* people implement features with no clear purpose or value (really?)
* there is no point at which you say "ok, that's done _well_, let's move on"

-- 
Martin <http://launchpad.net/~mbp/>