On software quality and engineering

[Matthew Hawkins]

Michael Still (mikal at stillhq.com) wrote:
> Another example, the linux kernel must have tens of millions of dollars
> worth of development time spent on it a year, with real smart people, but
> they too need a code freeze to stabilize 2.5...
> 
> How do you get around this? I suspect a lot of the answer is "the unix
> way" anyway. Many small, well tested apps, which integrate together well.

This is pretty much what the Extreme Programming model is about.  That
model advocates test-first development of modular components (and lots
of other fun stuff)

I think there's a major difference between the Linux kernel and, for
arguments sake, TRIM ;) which is the fact that Tower Software have the
ability to dictate what will go into the next version of TRIM, which
will be influenced by customer feedback and any registered bug reports
and any R&D they're doing in the field.  What goes into the Linux kernel
however is driven not by any solid design or goal, but by "market
forces" if you like.  USB devices came out, the support wasn't in the
kernel, someone got irritated enough by the itch that they scratched it.
Even subsystems such as the VM or networking layer which in the past
have recieved big rewrites, while at first glance may have seemed to be
a goal, were in fact mainly a dictation of the maintainer that "hey,
this is shit, next development cycle I'll be fixing it".

What I'd like to propose in regard to code freezes is this scenario;
perhaps they exist because, in the case of some commercial application
software, it was insufficiently analysed and designed before
implementation took place.  In the case of the Linux kernel, changes to
major subsystems (VM for example) can affect the way other things behave
which can then in turn uncover flaws, hence there needs to be some time
set aside to detect, analyse and erase these problems.

Another possibility is marketing... people like having a version number
attached to something, they feel more comfortable running "2.6.1" than
something labelled "2.6-SNAP_2002110401" because the latter sounds
intimidating, even though it could be exactly the same actual product.
Now in order to provide that trust in quality and reliability, you need
to have "2.6.1" showing as few flaws as possible, which means putting a
deadline to active feature development and then concentrating on ironing
out what you have.  With enough clued developers though, it should be
possible to have two lines of development going - mozilla does this at
the moment.  That way active featurism and all that fun R&D stuff we all
love isn't halted by the more mundane and boring drudge work ;-)

-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20021104/48c6ac03/attachment.bin