On Wed, Mar 17, 2010 at 1:21 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 17.03.2010, at 21:03, Ken G. Brown wrote:
> >
> >
> >
> >
> >
> > On 2010-03-17, at 12:52 PM, Alexander Lazarević <laza at blobworks.com>
> wrote:
> >
> >> On Wed, Mar 17, 2010 at 19:10, Ken G. Brown <kbrown at mac.com> wrote:
> >>> In my experience it is almost always better to think things through and
> fix known issues instead of rushing for some arbitrary deadline.
> >>
> >> I think this depends on our goals. I would like to see us aiming for
> >> continuous improvement rather than instant perfection at some distant
> >> time in the future. And my understanding of continuous improvement
> >> also includes more frequent releases.
> >> Rebasing the trunk tree on 4.0 makes an excellent goal for me and
> >> would justify a 0.1 incremented release.
> >>
> >>> Do it right the first time.
> >>
> >> This would make having sex a misión imposible ;)
> >>
> >> Alex
> >>
> >
> > You've got a good point there! :)
> > However I see that perhaps generalisims don't always apply.
> >
> > I am referring to the conclusions that HP came up with years ago when
> they studied why the Japanese manufacturing seemed to be doing so well. They
> evidently sent a team over to study Japanese management techniques. After
> some time they discovered that they appeared to strive for incremental
> improvement, and if they discovered a defect, say in an electronic board,
> they would take the time to not only correct the defect, but also fix the
> underlying cause of the defect, always working towards the long term
> improvement of the processes, not the short term gain. US manufacturing
> tended towards the short term only.
> > HP instituted quite a few of these improved concepts in their board
> manufacturing and as I recall saved something like $20 million the first
> year, just in reduced inventory of electronics waiting for testing.
> >
> > Their conclusion was 'do it right the first time' even if it makes the
> schedule slip. If you know there is something wrong, take the time to fix.
> >
> > Anyone interested can grab some of the well known books on Japanese
> Manufacturing for some good concepts.
> >
> > And I've personally had to deal with fixing things on customer sites that
> were rushed out unfinished to meet an arbitrary deadline. It's very
> expensive and embarassing to say the least.
> >
> > Let's not rush 4.1 out to try to cover the shortfalls caused by rushing
> 4.0 out with fanfare even before the deal is signed and sealed.
> >
> >  Ken G. Brown
>
> That all good and true when you develop a product.
>
> In a volunteer-driven open-source project the mantra is "release early,
> release often". If we can get into a steady release rhythm then there is no
> need to hold one release for a particular feature, because the next one is
> right around the corner.
>
> So, propose the blockers to 4.1 now. The release manager will decide if
> it's worth holding the release for them or not. We don't want to "rush" this
> release by ignoring those blockers, but we want it out swiftly on the heels
> of 4.0.
>

+1 x 3


>
> - Bert -
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100317/e24bc916/attachment.htm