Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
On Thu, Feb 11, 2010 at 5:02 PM, Aaron Bentley aa...@canonical.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jonathan Lange wrote:
On Wed, Feb 10, 2010 at 11:49 PM, Aaron Bentley aa...@canonical.com 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 DD 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('me...@code.launchpad.net',
+ [message.get('from')],
+ 'Error Creating Merge Proposal', body)
+ return
try:
bmp = source.addLandingTarget(submitter, target,
needs_review=True)
Now, to me it
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonathan Lange wrote: On Thu, Feb 11, 2010 at 5:02 PM, Aaron Bentley aa...@canonical.com 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
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
On 13 February 2010 01:45, Aaron Bentley aa...@canonical.com 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/ ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
On Thursday 11 February 2010 02:54:46 Tim Penhey wrote:
I think the guts of what Aaron is getting at here is the following:
* Do you expect _all_ questions to be answered for _every_ piece of work?
This doesn't really work for trivial or simple bug fixes
* Is the Launchpad Enhancement Proposal Process necessary for _every_
enhancement? Even minor ones?
Tim
From the page itself:
{{{
You do not need to follow this process if:
* you are making a change that's not visible to users,
* you are fixing a shallow defect, or
* you have answers for each item on the ReadyToCode checklist
}}}
___
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
On Wed, Feb 10, 2010 at 11:49 PM, Aaron Bentley aa...@canonical.com 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
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
On Thu, Feb 11, 2010 at 2:31 AM, Ian Clatworthy ian.clatwor...@canonical.com wrote: Jonathan Lange wrote: Hello, I've been thinking a bit about how we can achieve three[1] things: * avoid reworking features * avoid working on silly features * make our features so good that we have annoying fanboys queueing outside our retail outlets on release day In my experience, great products with annoying fanboys are the end result of 1000s of great decisions: every label, every widget, every workflow, every error message, etc. The primary challenge in a large software development team is how to distribute (wise) decision making. Ultimately, it's ideal if every software engineer gets the vision and makes smart choices accordingly. Failing that, team leaders need to be capable of getting it right. I very strongly agree. I have little or no idea on how to make that happen or (more realistically) get better at what we already do there. I've been reading Mary Tom's latest book on Lean SD this week. They put a huge emphasis on managing flow: finding what's slowing you down from delivering value faster. They also caution against introducing new processes that solve occasional problems: it can be better to wear the cost of rework (say) now and then than to slow down every change. I know what you mean, and I agree with the point. I don't think this is one of these cases. Sometimes the fastest way to improve quality is to simply fix lots of bugs. The primary argument against doing that is opportunity cost: could the time be better spent on delivering new features instead? That's never an easy call. I think your templates are great for new features. If fixing small bugs takes too long though, then that process needs to be improved IMO. I'd be hesitant to impose additional overhead on small changes. For small bug fixes, I'm really proposing spending less than ten minutes looking through a checklist with eleven points. The LEP thing is only for new features. Mary Tom also talk a lot about knowing which things are ready to code. Fixing small bugs takes too long. I'm not trying to solve that problem now. It's a well-known and frequently-discussed problem within the team, but as far as I can tell we've made little progress toward solving it. Any help you have to offer on this would be appreciated. We should also spend a lot of time fixing bugs, but I'm not trying to solve that problem now. I have contended for a large chunk of dedicated time for the whole Canonical Launchpad team to spend fixing bugs. We aren't going to get something like that until we can demonstrate how we'd manage it and what kind of results we'd get for Canonical. It is my hope that considered use of a kanban board will allow us to dedicate a significant fraction of our work-in-progress items to fixing bugs in existing features. I really, really believe that big design up front is a wasteful practice that produces crappy software and unhappy developers. I would only be happy with these things becoming a part of our process if they were iterative and if the documents do not become ends in themselves. With that in mind, I want to know your thoughts on the whole thing. The essential thing is to not make yourself a bottleneck. That's *very* easy to do in a role like Product Strategist or Architect. I think it's unavoidable for now. I definitely want to spread the responsibility out further, but I think that in the early, experimental phase it makes sense to centralize. Also, one trick that's appropriate now and then is to write documents that have ongoing value (e.g. end user documentation) instead of documents that become obsolete. I agree. The thing is, I really want these things to focus on what problems we are solving, rather than how we are solving them (set-based design!). To me, this is the kind of thing that could easily be turned into the introductory paragraph of a blog post, but not user guides. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
On February 11, 2010, Jonathan Lange wrote: 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. Yes, it's the product strategist responsibility to ensure that we are crystal clear on what feature we implement/rework and why. It's not his responsibility to write up everything or come up with all the ideas. So he's probably not the only trigger of the process, but he's definitively the referee of it. -- Francis J. Lacoste francis.laco...@canonical.com signature.asc Description: This is a digitally signed message part. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
On Feb 11, 2010, at 12:31 PM, Ian Clatworthy wrote: Sometimes the fastest way to improve quality is to simply fix lots of bugs. The primary argument against doing that is opportunity cost: could the time be better spent on delivering new features instead? That's never an easy call. I think your templates are great for new features. If fixing small bugs takes too long though, then that process needs to be improved IMO. I'd be hesitant to impose additional overhead on small changes. Something to keep in mind, IMO, is the great success we had with LP 3.0. I think there will always be grumblings when you change anything (witness Facebook ;), but with my upstream hat on, I think LP 3.0 was an enormous positive leap in usability. Everyone was lazr (sorry :) focused on a common task and we fixed tons of little bugs. In hindsight it also seemed really pretty agile, at least once we got going. Let's do more of that. -Barry signature.asc Description: PGP signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jonathan Lange wrote:
On Wed, Feb 10, 2010 at 11:49 PM, Aaron Bentley aa...@canonical.com 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.
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.
I got that implication from it's not going to happen unless we all
refuse to make anything short of excellent. Refusing to make anything
short of excellent would mean refusing to make anything merely useful or
good.
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?
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.
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.
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.
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?
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('me...@code.launchpad.net',
+[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
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
On 10 February 2010 13:22, Jonathan Lange j...@canonical.com wrote: Hello, I've been thinking a bit about how we can achieve three[1] things: * avoid reworking features * avoid working on silly features * make our features so good that we have annoying fanboys queueing outside our retail outlets on release day Ultimately, it's not going to happen unless we all refuse to make anything short of excellent. However, maybe some structure can help. In particular, I think a little structure around the area of defining features will go a long way toward achieving those three goals. By a coincidence that I can only explain by appealing to astrology, I've written three documents to help with this. 1. https://dev.launchpad.net/ReadyToCode It's a very short list. I'm proposing that before we begin work on _anything at all_, we run through this checklist: bugs, refactoring, features, whatever. 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. It's worth noting that the LEP is *absolutely not* the place where implementation design happens. It's where we collect requirements. I only grudgingly included the UI mockup section. 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] 3. https://dev.launchpad.net/LaunchpadEnhancementProposalTemplate This is a template for 2. Should be quite straightforward. 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. I would only be happy with these things becoming a part of our process if they were iterative and if the documents do not become ends in themselves. With that in mind, I want to know your thoughts on the whole thing. I think this is a bloody good experiment, thanks for writing (and thinking) this up. There's one emotional reaction I noticed erupting as I read the process proposal: oh no, more wikis to edit?! Perhaps some of the work we can do on Blueprint which will actually give us value is work that will rid us of the need to edit wikis to keep structured documents. The template you are proposing, for example, could be very easily encoded in a form. Also there are other document management solutions that don't make you sweat so much. Tom ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
Jonathan Lange wrote: Hello, I've been thinking a bit about how we can achieve three[1] things: * avoid reworking features * avoid working on silly features * make our features so good that we have annoying fanboys queueing outside our retail outlets on release day In my experience, great products with annoying fanboys are the end result of 1000s of great decisions: every label, every widget, every workflow, every error message, etc. The primary challenge in a large software development team is how to distribute (wise) decision making. Ultimately, it's ideal if every software engineer gets the vision and makes smart choices accordingly. Failing that, team leaders need to be capable of getting it right. I've been reading Mary Tom's latest book on Lean SD this week. They put a huge emphasis on managing flow: finding what's slowing you down from delivering value faster. They also caution against introducing new processes that solve occasional problems: it can be better to wear the cost of rework (say) now and then than to slow down every change. Sometimes the fastest way to improve quality is to simply fix lots of bugs. The primary argument against doing that is opportunity cost: could the time be better spent on delivering new features instead? That's never an easy call. I think your templates are great for new features. If fixing small bugs takes too long though, then that process needs to be improved IMO. I'd be hesitant to impose additional overhead on small changes. I really, really believe that big design up front is a wasteful practice that produces crappy software and unhappy developers. I would only be happy with these things becoming a part of our process if they were iterative and if the documents do not become ends in themselves. With that in mind, I want to know your thoughts on the whole thing. The essential thing is to not make yourself a bottleneck. That's *very* easy to do in a role like Product Strategist or Architect. Also, one trick that's appropriate now and then is to write documents that have ongoing value (e.g. end user documentation) instead of documents that become obsolete. HTH, Ian C. ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
I think the guts of what Aaron is getting at here is the following: * Do you expect _all_ questions to be answered for _every_ piece of work? This doesn't really work for trivial or simple bug fixes * Is the Launchpad Enhancement Proposal Process necessary for _every_ enhancement? Even minor ones? Tim ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] [RFC] Launchpad Enhancement Proposals
On Thu, 11 Feb 2010 12:31:27 +1000, Ian Clatworthy ian.clatwor...@canonical.com wrote: Also, one trick that's appropriate now and then is to write documents that have ongoing value (e.g. end user documentation) instead of documents that become obsolete. Indeed, I like combining specs and documentation, but I don't do enough of it. You do the UI design by writing the documentation for the feature despite it not existing, and where you would put a screenshot you put a mockup. You can then add another page that explains more about what is going on under the hood, which can act as your architectural specification for the feature. This means that you get the benefits of a specification, but it keeps its value after the implementation is done, and doesn't grow out of date like a spec will as you keep the documentation up to date as things change over their lifetime. It also includes a user experience focused approach as it forces you to think about how people will use it first, and the goal of a simple to describe interface nicely meshes with your desire to write less documentation. There are clearly some problems though, it adds a fairly large amount to the cost of changing direction in the middle of implementation, good documentation doesn't always match up with what you need to think about when designing something, we don't all make great documenters, and rolling out a half-finished feature becomes trickier as you have to edit the documentation so people don't get confused. Thanks, James ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
