launchpad-dev team mailing list archive

[Ian Clatworthy <ian.clatworthy@xxxxxxxxxxxxx>]

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.