| |||||||||||||
I think it was Steve Jobs...I think it was Steve Jobs...Posted Aug 9, 2008 14:28 UTC (Sat) by qu1j0t3 (guest, #25786)In reply to: Kernel Hacker's Bookshelf: The Practice of Programming by surfingatwork Parent article: Kernel Hacker's Bookshelf: The Practice of Programming
...who claimed that the ratio is more recently closer to 50x. I see no reason to disbelieve him. 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 code.) 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.
(Log in to post comments)
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.
|
|||||||||||||