Posted May 8, 2008 18:37 UTC (Thu) by drag (subscriber, #31333)
Parent article: Quotes of the week
> [T]he kernel team has evolved from a small team of buddies to a large enterprise. And to
survive this evolution, we may need to apply the immoral principles found in big companies.
*BTTZ* WRONG. Try again.
Now I am a big pro-capitalist guy and I accept that it's big corporations that make the world
go around (while small ones do all the work), but there are some things that should be avoided
that are common to large industries...
American-style management practices. These things are f-ing horrible. The very idea of
establishing a sort of adversarial competition internally (or even externally) in order to
help manage things is just one very huge hunk of _very_bad_idea_.
This management school of thought says such things as employee competition will lead to
improvements and higher rates of output. People are encouraged to do good and discouraged from
doing bad.... This totally back-fires almost every time.
Industry works because the workers are so good at what they do. If they are able to do good
work it's _DESPITE_ those style of management practices, not because of them.
People _ALREADY_ want to do good work. They don't want to do bad work. They don't want to
introduce bugs or let other people deal with their dirty laundry. They introduce bugs into the
code because that's just what human beings do. You can play games and try to force people's
hands at fixing bugs by refusing to accept other hunks code and all that.. but it really isn't
going to work except under specific cases. (this means that occasionally, yes, refusing
patches are called for, it's just the exception that makes the rule)
Everybody here involved in kernel development is involved because they _want_ to do good work.
They are all very smart people and probably can do any number of things that will make them
far more money. There are tons of other kernels and other peices of software they can be
having fun on. You want them doing what they are good at.
Purposely introducing inefficiences into your system of development in order to force some
sort of positive outcome is just bad. The answer is not to slow down development... you _want_
fast, efficient, development. This is a good thing.
Bugs are going to happen. There is nothing you can do about. Big changes bring lots of small
bugs with it. Drivers that don't get used very often, or are only used under certain
circumstances will have more bugs.
Right now the Linux development stuff depends entirely on it's developer base to detect bugs
and absolutely depends on the end user to report bugs. In fact those end users are as
important as anybody else in the software development process.
Ok... as programmers you guys love to generate lots and lots of data.
What is needed is some solid statistical analysis of the Linux development process. This is
the _GOOD_ stuff from American industry. The old-school stuff of statistical analysis that
certain American industrialists* developed in the 40's and the Japanese adopted in the
50-60's. (and the Americans quickly forgot leading to the low-quality industry we had in the
Identifying and eliminating weaknesses in the design and process, not trying to force workers
to do something they can't. It's about cooperation towards a common goal, not finding some
quick-fix trick to make people work harder or be forced to do what you want.
Something like... driver bugs are unavoidable. Obscure hardware and lesser used hardware and
buggy hardware will all introduce more bugs no matter what you can do... even if the
programmers are perfect (which they are not). So what can you do minimize the effect of these
bugs since they _cannot_ be eliminated in any practical sense?