launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #04504
Re: Some launchpad data model thoughts
-
To:
launchpad-dev@xxxxxxxxxxxxxxxxxxx
-
From:
Ian Booth <ian.booth@xxxxxxxxxxxxx>
-
Date:
Fri, 27 Aug 2010 15:45:57 +1000
-
In-reply-to:
<AANLkTik=jMDtbdMdp+fpTxWWJSk7VoaQSRmTgXG02eKn@mail.gmail.com>
-
User-agent:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100821 Thunderbird/3.1.2
>
> I answered several at once before, and missed this point.
>
> Assuming you mean 'Multi-Generational Product Plan' by MGPP; we don't
Yes.
> have a formal MGPP at the moment; we have adopted an agile approach
> and each team is using kanban to balance:
> - bug fixing, tech debt
> - feature work
>
> At the architecture level, my current cards are:
> - performance - driving page load times down to 1-2 seconds each
> - releasing-features-when-they-are-done - helping us have less
> inventory and faster cycle times
>
No worries. My opinion is that larger projects need a mix of agile and
more longer term planned approaches (for architectural and other related
concerns where a bigger picture view sometimes is more beneficial).
These bigger picture items often necessarily span several sprints,
especially when it comes to architecture level refactoring.
> I've certainly been identifying the mapping structure as a key driver
> for why performance is heard in launchpad, and I'm a huge fan of
> testing with substituted interfaces - dependency injection : the bzr
> test suite uses that, and the inverse, interface conformance testing -
> quite a lot.
>
I love dependency injection. It works best when the coupling between
modules and/or layers is managed well and also when used consistently
throughout the product. eg it tends to break down when one module uses
it and another doesn't and they both access a shared component.
> So - yes, addressing this in some fashion is in the MGPP (in that its
> on my radar), but we its not in anyones queue yet. Doing it
> incrementally is, of course, sensible, but I think that we need
> infrastructural changes in lower layers (storm) to really do it well,
Agreed.
> and we'll want those to be done without breaking the API, so that we
> can then roll them out incrementally in LP itself. We can and should
> prepare LP to take advantage of changes to Storm, and I encourage
> anyone that wants to help move this forward to hop onto the storm
> channel and list, and get stuck in :)
>
I've signed up. Not sure how much value I can offer short term but I'm
certainly interested in doing what I can to help.
Ian
References