launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

On 10 February 2010 13:22, Jonathan Lange <jml@xxxxxxxxxxxxx> 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