- "Lines of code" is a meaningless metric. Please stop using it.
- Charles obviously did something when he appeared to be doing nothing. What? Unfortunately, we're never told.
- There is no treatment of the things that likely are important: analysis, design, prototyping, feedback, fine tuning, etc. Did either programmer try any of these?
- The story infers that using modern magical brilliance is better than using tried and true methods, without ever mentioning what either one is.
I can imagine this story being true. Just as likely, I can imagine the opposite being true. Nothing offered, nothing learned.
* "Lines of code" is a meaningless metric. Please stop using it.*
I can agree that LOC is a terribly abused metric, but it is not completely without meaning. It's just really rough and better left untouched in decisions involving money.
I can imagine this story being true. Just as likely, I can imagine the opposite being true. Nothing offered, nothing learned.
I think it's just an invitation to reflect on the ways that this story comes true. People mistake needless, unhelpful processes for "tried and true methods" and software "architects" frequently over-engineer and create solutions worse than the problems.
I'm not under any illusions that you (and most people here) don't already understand this. It probably wasn't aimed at you. There are many programmers today who don't understand that this kind of story plays itself out every day to some degree. The fact that the opposite story can also happen doesn't detract from the point that is being made.
No, "Lines of code" is not a meaningless metric. I recently had to take over an existing code base for a module in our system and upgrade it to support the next version of our system's ICD. After spending some time trying to wrap my head around the existing 8800 lines of code, I concluded that it would be better to do a complete rewrite. The rewrite took a week or two and ended with 1950 lines of code that did essentially the same thing!
Now, if we make the reasonable assumption that my rewrite was not a candidate for the IOCCC or Perl Golf, I think it's pretty clear that lines of code is not meaningless. A >75% code reduction while maintaining the same functionality under reasonable development conditions is almost always going to make it easier to test, debug, and maintain the system/module. (This assumption isn't unsubstantiated either. In a code review, I was even complimented on the quality of my documentation.)
You hear about these kinds of vast disparities among software developers all the time, but I still find myself shaking my head that I actually saw it in real life. Now I'll freely admit that "lines of code" is mostly meaningless the way it is usually used. But don't throw the baby out with the bath water.
What if your 1950 was less expressive and more cryptic to understand, and the 8800 was very verbose and easy for a newbie to pick up?
So you can't measure less LOC means it's better, it really depends on the quality of the code from a maintainability standpoint not just the size of code.
First of all, it wasn't. Like I said, as long as we assume reasonable effort towards readability (i.e. we're not code golfing), this kind of size difference is usually going to be much easier to maintain. Code size correlates very well with maintainability.
The guy who did the code review found the 1950 very readable, and much simpler.
On the other hand, the instant a manager starts making salary/bonuses proportional to the inverse of code size, you'll find that my assertion becomes completely false. But if you start from an empty slate of two developers making a genuine effort to code a good solution, the less LOC rule will probably be pretty accurate. Especially when one program is 4x the size of the other. (See http://paulgraham.com/head.html for a related take on the same idea.)
There are no absolutes. But that doesn't make these metrics useless.
There is actually one point missing from his list. I would put it after #5 and that is "write provable programs". I suspect Paul does this anyway, but it is a good thing to mention. This is scary to some, but PAIP has some very nice examples of this.
And rereading this essay again shows at least part of the motivation for making arc a smaller language than lisp.
I disagree: LOC is useful, but in an inverse way than many large organizations claim. Smaller is better.
As a long-time programmer, it was pretty clear to me what Charles was doing when others around him thought he was doing nothing: analysis, design.
And sometimes if you get a problem solved right, it doesn't need tuning, and if the solution is a small number of lines of code, your prototype might be just what you ship. Many large entrenched shops cannot imagine that this can possibly be true, so the bureaucracy resists or eliminates any such solutions.
To me what is troubling about this story is that it represents what happens in software organizations--both sides.
- "Lines of code" is a meaningless metric. Please stop using it.
- Charles obviously did something when he appeared to be doing nothing. What? Unfortunately, we're never told.
- There is no treatment of the things that likely are important: analysis, design, prototyping, feedback, fine tuning, etc. Did either programmer try any of these?
- The story infers that using modern magical brilliance is better than using tried and true methods, without ever mentioning what either one is.
I can imagine this story being true. Just as likely, I can imagine the opposite being true. Nothing offered, nothing learned.