launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

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

Jonathan Lange wrote:
> On Thu, Feb 11, 2010 at 5:02 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
>> 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?

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

Perhaps I'd counter by adding a constraint that we must notify the user
*promptly*.  But I am really working backward from an established solution.

> Reflections / Thoughts:...

Agreed.

> So I guess I'm in favour of phrasing it strongly then trusting you to
> break the rules when it makes sense

I don't have a lot of respect for rules that I have to break in
non-exceptional circumstances.

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

A few ideas:
 - Convince the team leads that it is worth it to themselves as
   programmers and it will trickle down.
 - Point out success stories.
 - Convince people to give it a good, solid try, and analyse the
   outcomes with them afterward.  If they feel it helped them, encourage
   them to tell others about it.

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

Quite likely.  I think that it's very hard to make rules that are clear
to everyone all the time.  I think hyperbole reduces clarity further.

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

What scale?  I can certainly contemplate features that take less than a
day to implement.  The conflict tracking recently added to merge
proposals, for example.

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

I was assuming a context where we have already decided to implement the
change.

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

The problem is that I will get blocked on you.  This will stop me from
doing work that I am supposed to be doing, and the document suggests
that there is nothing I can do to fix this.  I must wait until you,
entirely of your own accord, you decide to address the work I am blocked on.

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

That may be, but the evidence suggests people would prefer to use other
tools, and until there is a serious commitment to improve blueprints, I
don't see the point of using them.

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

Yes, but the idea of refusing to work on something that isn't excellent
means that we must design a feature thoroughly before we are ready to
code.  That, to me, is big design up front.

So providing a new set of procedures for doing design up front while
simultaneously saying you wanted to avoid BDUF seemed contradictory to me.

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

I can understand that, and I think we've made a lot of progress, but I
also think that changing our development methodology is a serious
matter, and it's worth spending a bit of time on.

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

iEYEARECAAYFAkt1aYQACgkQ0F+nu1YWqI3GyACfR26epZDi5pmbnV3nO6KPszIL
iM4AnR1TBXGBUmh6L5d5Lg4GDeRUZW2q
=WINC
-----END PGP SIGNATURE-----