User: Password:
Subscribe / Log in / New account

Kernel Hacker's Bookshelf: The Practice of Programming

Kernel Hacker's Bookshelf: The Practice of Programming

Posted Aug 9, 2008 13:58 UTC (Sat) by surfingatwork (guest, #50868)
Parent article: Kernel Hacker's Bookshelf: The Practice of Programming

May be out of place considering you are talking specifically about kernel programming, however
the claim that programmers range from 1x to 10x was published in 1975, 33 years ago.

Now we have Java which is by design for average programmers. There is plenty of average
programming to be done -- more software is coded for in-house than best of breed. The very
first programmers were recruited from chess grandmasters since programmers didn't exist back
then. A lot has changed since then, and I'd like to see how well this 10x claim holds up now.

Also the claim that projects are like pregnancy, throwing more workers at the problem will not
speed things up seems to be in disagreement with the industry practice of death marches. If
Fred Brooks is still correct then why do industries do death marches (e.g. video games)?

(Log in to post comments)

I think it was Steve Jobs...

Posted Aug 9, 2008 14:28 UTC (Sat) by qu1j0t3 (guest, #25786) [Link]

...who claimed that the ratio is more recently closer to 50x. I see no reason to disbelieve

While a simple *doubling* of productivity and clarity could easily be gained through the
insights of any of the great books mentioned, one should not interpret these ratios to mean
"10x or 50x more lines of code" (and I would be suspicious of programmers who 'wear out
keyboards'. If you are doing more typing than thinking, you're on irc, not writing great

Any old programming fart (guilty) will cite Dijkstra's observation that a line of code is a
liability, not an asset. So real productivity gain must be through leverage, tool-building,
and paradigm shifts - and reuse, not reinventing wheels.

I think it was Steve Jobs...

Posted Aug 14, 2008 9:54 UTC (Thu) by forthy (guest, #1525) [Link]

Lines of code is a nonsensical measure. A good programmer writes clean, concise, and short programs. Overall, he might produce 10x lines of code of a bad programmer, but it's easily 100x the functionality. Since measuring lines of code becomes metric of choice, bad programmers find silly way of expanding their LOC numbers without actually doing anything useful - these techniques actually are harmful, since they make the program more difficult to maintain and understand (typical and very dangerous way to achieve lots of LOCs: cut&paste instead of factoring, i.e. "call by editor" subroutines).

One book about the same general topic, that's on my bookshelf (Thinking Forth, fortunately available for download under a CC license) has a nice illustration of the problem: Clever programmer shows his short solution, and stupid programmer shows his much longer solution, where he needs a ladder to measure the height of the printed listing. The boss asks the clever programmer, when he'll start to write serious programs. LOCs can be pretty bogus.

The management problem is a problem of judgement: As long as management knows little about what the people below actually do, there's no objective judgement. Good programming has many paradoxical aspects that take it from simple objective measurements: If you write good code, it's compact. It's fast, as well. It's probably even easy to understand what it does, because it's elegant. A kludgy hodgepodge may show up much more on any "objective" measurement: It's taking more LOCs, it's burning more CPU cycles. That's not the point of a good program. Who's the hero in a free software project? The person who wrote 10k LOCs, or the person who deleted 10k LOCs, and replaced them with 100 lines which do a better job? Certainly the latter.

Programming still is an art. When you study history of art, you don't become a good painter; when you study computer science, you don't become a good programmer. When you don't study history of art/don't study computer science, your chances are even less. You have to learn the actual art, too, and also the craftsmanship (every art bases on craftsmanship). Books like that can help.

Kernel Hacker's Bookshelf: The Practice of Programming

Posted Aug 14, 2008 5:40 UTC (Thu) by dkite (guest, #4577) [Link]

The fact that industry does something proves nothing except possibly

The idea of less people, more skilled more productivity is cross industry
sectors. Smart construction people know that, and many a foreman has made a
name and career for himself by choosing a small competent crew, feeding them
the necessary support and materials, and outperforming other crews with far
more people.

The real problem is determining skill level and productivity, and getting
used to the idea that the company's future is dependent on a few key
individuals that don't sit in the executive suite.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds