launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Thu, Feb 11, 2010 at 2:31 AM, Ian Clatworthy
<ian.clatworthy@xxxxxxxxxxxxx> 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