| |||||||||||||
what Hans is right aboutwhat Hans is right aboutPosted Jul 29, 2006 21:12 UTC (Sat) by pimlott (guest, #1535)In reply to: what Hans is right about by bronson Parent article: Quote of the week
You can babble on a mailing list about something for months or you can hack out a prototype.Writing kernel code, even a prototype, is quite hard and time-consuming. At the beginning of a project, this time is better spent on the design. Which technique do you suppose will be more instructive?You've given a false choice, obviously. Thoughtful design, on-paper analysis, modelling in a formal or semi-formal language are all highly instructive (and they don't require chasing down oopses!). Writing a prototype is also instructive, but bang-for-time, it may not be the best. I have known gifted designers who could write a spec much faster than they could write the code--and the spec proved implementable and solved the problem! NB: Most people can't do this. But some can. Maybe our disagreement comes down to whether such people really exist. My experience says yes. Sure, overdesign is a danger. It's critical to identify the good designers and not listen to every babbling bozo (which may be hard in and of itself). And ever then not every design will work. But there are big payoffs too. And, if by "disparage expertise" you mean that all developers are treated more or less equally, regardless of their experience, well, you might be right!Come on, that is patently false. Linus is treated very differently from most developers, and the same to a greater or lesser extent goes for the rest of the pantheon. The problem is that writing Linux code is the only way to get any respect among Linux developers, who are generally indifferent to the other accomplishments and expertise of a would-be contributer.
(Log in to post comments)
what Hans is right about Posted Jul 29, 2006 23:05 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] if you are willing to invest the time to readk the kernel list (and yes, it does take quite a bit of time) you will find that the kernel developers are not at all opposed to people designing things for the long-term, it's just that they are not willing to pay attention to people who say 'stop what you're doing and wait for someone to design this'
there are quite a number of very experianced people who pop up on the kernel list once in a while to weigh in on something. when they do they are listened to and things are useually adjusted to accomodate them.
the situation is something like this
code that works trumps a design that's not implemented
and in all cases evolutionary changes win over rip-out-and-replace (although there are some kernel developers who are famous for long patch series that incrementaly replace core functionality, the key is that each stop stands alone)
none of this sits especially well with a lot of the 'specify, design, then code' folks. however if they keep working rather then getting discouraged the results of their work does stand a good chance of being accepted
|
|||||||||||||