Date: Tue, 22 Jul 2003 22:20:58 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Paul Robinson <paul@iconoplex.co.uk> Cc: FreeBSD Chat <freebsd-chat@freebsd.org> Subject: Re: What does "enterpise" mean? Message-ID: <3F1E1B3A.7EABD098@mindspring.com> References: <E28BB957-BBEF-11D7-B762-0030657B5F1E@alltel.net> <3F1D1D56.5060107@iconoplex.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Robinson wrote:
> Jerry Hicks wrote:
> > In the case of one major Linux vendor's enterprise products they are
> > even pitching 'longer release cycles' as a product feature.
> >
> > "We're repackaging stale open source software and charging you extra
> > for it."
> >
> > Oddly enough, all the pointy hairs I know think that is a good thing.
>
> There is a reason for this. PHBs within enterprises understand "risk" in
> terms of product development and the impact short release cycles can
> have. A longer release cycle implies to them that the company is taking
> longer over it due to testing and therefore the risk on deployment is
> lessened.
>
> In my opinion, this attitude should be applauded, rather than the "let's
> rush it out of the door right now and see what happens" appraoch. But
> then, my degree is software engineering, so I'm bound to say that...
There are many facets to longer release cycles:
o You wait longer for fixes ("Fixed in the next release")
o There's more time for doing testing
o There's more time for cramming new features in, instead of
doing testing
o The vendor gets to save money on marketing, collateral
material, etc..
o The vendor gets to lose money on a longer amortization
schedule for an income stream that now has to last a lot
longer
o There are less people actually working on the product
o The developers/designers/architects could "get it wrong",
and you could end up with a Blivit (ten pounds of manure
in a five pound sack)
Etc..
The PHB's aren't always right, and they aren't always wrong. It's
probably more correct, overall, to keep your developers in suspense,
so that they can't try to look too far ahead; three months of some
amount of uncertainty, where the developer's favorite feature may
or may not get in if they let implementing it drag out too long is
probably a good balance. It gives you a good three months in which
the only code that's going to get done is the code that needs to
get done to clear bugs, rather than cram in new features.
My first boss out of college taught me something that I've never
forgotten, and it's always stood me in good stead: "Eventually, a
software company has to ship software". I may have left that
company behind a long time ago (after helping take it from just 2
employees to 18 employees), but that lesson has really stuck with
me and shaped my idea of acceptable practice.
-- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F1E1B3A.7EABD098>