3 ms·

Allow me to play devil's advocate for a moment: Most good writers will tell you that shorter is almost always better. You want to express your thoughts in the

Allow me to play devil's advocate for a moment: Most good writers will tell you that shorter is almost always better. You want to express your thoughts in the most succinct way possible. Review your own writing to remove as much as you can, then hand your draft off to an editor who'll try to cut even more. And yet, many writers are still paid by the word, and many book contracts still specify target page counts. Because even though shorter is better, the shortest possible length of a given text still serves as a rough measure of that text's breath and complexity. Is code any different? Yes, paying or evaluating programmers by lines of code is going to lead to misaligned incentives. However, I'm not convinced the dynamic is any worse than for prose. Bill Atkinson spent a week removing extraneous code from QuickDraw; an author might spend a week cutting extraneous subplots from a novel. Word count is still a useful metric for the author. Perhaps the difference is that non-writers tend to be more familiar with the writing process than non-programmers are with coding. If an author was working on revising a novel, no one would ask them how many words they'd written that week. Or maybe word count measurements are in fact making everyone's prose worse and we should do away with them too.

BlargMcLarg 4y ago
The code is different in the sense that good abstractions and function definitions, when not used in excess, will severely cut down the amount of lines. However, given the same amount of time and not a lot of time spent on thinking about abstractions, odds are they will end up with fairly similar LoC counts. Just developer A will have written more features, whereas developer B will have done the same thing over and over, without having the same features. That's where your example of writers should take hold too: good writers stop being paid by the word and start being paid by number of sales. The same should be done with devs. That said, the entire thing gets tossed out of the window when considering significant portions of developers will overthink abstractions, fiercely hold onto overabstractions (which end up bloating LoC), have discussions with each other ad nauseam, slow down code reviews over petty differences, and more.
- skrtskrt 4y ago
  Also if you write an abstraction then your teammates use it, the measurement on either you or your teammates or both is going to be skewed whether you’re going for high or low LoC. If
wirrbel 4y ago
You lost me at "Allow me to play devil's advocate for a moment"
- deleted 4y ago
  [deleted]
comfypotato 4y ago
It’s my understanding that Tolstoy was paid by the page (or something like that based on how many words he wrote). It’s an interesting analogy to code in that Tolstoy’s writing is wonderful. His style is delightfully monotonous. It’s interesting to note that the incentives you’re talking about don’t have to result in bad code just different code (in the hands of a good enough programmer).
- bombcar 4y ago
  Many authors had similar things (Dickens was serialized with portions printed weekly/monthly) and they often read better if you read them that way. Reading a Dickens novel cover-to-cover is somewhat like binging a TV series; it's too fast and you start to notice repetition, etc. But when spread out it's nice.
badsectoracula 4y ago
> And yet, many writers are still paid by the word, and many book contracts still specify target page counts. That doesn't really mean anything, after all some managers still judge productivity by LoC. They both can be bad. And at least IMO, using word counts for books is giving very wrong incentives. I've stopped reading non-fiction books because absolutely every single one i've tried to read over the years always *ALWAYS* gets way too wordy, spending entire chapters in what one could fit in a blog post. And i'm writing that as someone who also tends to err on the "wordy" side - both when writing and when reading (i.e. when in doubt, i think it is better to write more). But books tend to overdo it to fill those contract pagecounts.
- Wowfunhappy 4y ago
  Right, and that's why I said at the end of my post, it may just be that length is a bad metric in both cases. However, I'd posit that if you went into a forum of professional writers and asked how they felt about word count measurements, they'd be a lot more divided than we are regarding lines of code. Or, to pick another example, NaNoWriMo seems to be pretty popular among aspiring authors, and that's all about the wordcount. Maybe it shouldn't be—or maybe there's something we're missing. For example: it may be the case that lines of code is a useful goal during certain phases of a project—maybe while prototyping, for example. Just like how a target word count is useful when writing a rough draft, but obviously stupid while revising a draft. Although, an author might set a goal to get below a certain word count during the revision phase—and that again might be a useful target for programmers refactoring code.
njharman 4y ago
I would argue the bloated 10+ book series that fantasy and sci-fi have devolved into is the exact bad outcome of LoC or word count metrics.
- Retric 4y ago
  Customers pay by the word, as in the publisher prefers someone buys a 10 book series vs a 3 book series. However, people don’t buy programs like that. If Madden 2023 has 10x as many LOC as Madden 2022 the price doesn’t change.
markstos 4y ago
I worked at a print newspaper. They have target word counts not because it’s a great metric because that’s literally the amount of space they have for article on the page. Same for magazines. There is a target number of pages in the issue. Any business that publishes in both print and online still has that constraint. Online daily newsletters are designed to take so many minutes to read, which is calculated directly from the word count. So word counts often have utility. Coding sometimes has space and memory constraints but often it works best to optimize for maintainable code, which might be shorter or longer depending on the case.
deleted 4y ago
[deleted]
thenoblesunfish 4y ago
I think a key difference is that code needs to be maintained, often by someone other than the author. A great way to write a lot of lines of code is to write something you have to fix or update each week. On the flip side, you could spend weeks chasing a nefarious bug, costing millions of dollars, and fix it by changing one line. Put another way, the analogy with writing prose is a good one for "programming" as you do it in school where you are often crafting relatively small pieces of code and then calling them done, but is less applicable for "software engineering" where code lives a long time.

BlargMcLarg 4y ago

The code is different in the sense that good abstractions and function definitions, when not used in excess, will severely cut down the amount of lines. However, given the same amount of time and not a lot of time spent on thinking about abstractions, odds are they will end up with fairly similar LoC counts. Just developer A will have written more features, whereas developer B will have done the same thing over and over, without having the same features. That's where your example of writers should take hold too: good writers stop being paid by the word and start being paid by number of sales. The same should be done with devs. That said, the entire thing gets tossed out of the window when considering significant portions of developers will overthink abstractions, fiercely hold onto overabstractions (which end up bloating LoC), have discussions with each other ad nauseam, slow down code reviews over petty differences, and more.

skrtskrt 4y ago
Also if you write an abstraction then your teammates use it, the measurement on either you or your teammates or both is going to be skewed whether you’re going for high or low LoC. If

wirrbel 4y ago

You lost me at "Allow me to play devil's advocate for a moment"

deleted 4y ago
[deleted]

comfypotato 4y ago

It’s my understanding that Tolstoy was paid by the page (or something like that based on how many words he wrote). It’s an interesting analogy to code in that Tolstoy’s writing is wonderful. His style is delightfully monotonous. It’s interesting to note that the incentives you’re talking about don’t have to result in bad code just different code (in the hands of a good enough programmer).

bombcar 4y ago
Many authors had similar things (Dickens was serialized with portions printed weekly/monthly) and they often read better if you read them that way. Reading a Dickens novel cover-to-cover is somewhat like binging a TV series; it's too fast and you start to notice repetition, etc. But when spread out it's nice.

badsectoracula 4y ago

> And yet, many writers are still paid by the word, and many book contracts still specify target page counts. That doesn't really mean anything, after all some managers still judge productivity by LoC. They both can be bad. And at least IMO, using word counts for books is giving very wrong incentives. I've stopped reading non-fiction books because absolutely every single one i've tried to read over the years always *ALWAYS* gets way too wordy, spending entire chapters in what one could fit in a blog post. And i'm writing that as someone who also tends to err on the "wordy" side - both when writing and when reading (i.e. when in doubt, i think it is better to write more). But books tend to overdo it to fill those contract pagecounts.

Wowfunhappy 4y ago
Right, and that's why I said at the end of my post, it may just be that length is a bad metric in both cases. However, I'd posit that if you went into a forum of professional writers and asked how they felt about word count measurements, they'd be a lot more divided than we are regarding lines of code. Or, to pick another example, NaNoWriMo seems to be pretty popular among aspiring authors, and that's all about the wordcount. Maybe it shouldn't be—or maybe there's something we're missing. For example: it may be the case that lines of code is a useful goal during certain phases of a project—maybe while prototyping, for example. Just like how a target word count is useful when writing a rough draft, but obviously stupid while revising a draft. Although, an author might set a goal to get below a certain word count during the revision phase—and that again might be a useful target for programmers refactoring code.

njharman 4y ago

I would argue the bloated 10+ book series that fantasy and sci-fi have devolved into is the exact bad outcome of LoC or word count metrics.

Retric 4y ago
Customers pay by the word, as in the publisher prefers someone buys a 10 book series vs a 3 book series. However, people don’t buy programs like that. If Madden 2023 has 10x as many LOC as Madden 2022 the price doesn’t change.

markstos 4y ago

I worked at a print newspaper. They have target word counts not because it’s a great metric because that’s literally the amount of space they have for article on the page. Same for magazines. There is a target number of pages in the issue. Any business that publishes in both print and online still has that constraint. Online daily newsletters are designed to take so many minutes to read, which is calculated directly from the word count. So word counts often have utility. Coding sometimes has space and memory constraints but often it works best to optimize for maintainable code, which might be shorter or longer depending on the case.

deleted 4y ago

[deleted]

thenoblesunfish 4y ago

I think a key difference is that code needs to be maintained, often by someone other than the author. A great way to write a lot of lines of code is to write something you have to fix or update each week. On the flip side, you could spend weeks chasing a nefarious bug, costing millions of dollars, and fix it by changing one line. Put another way, the analogy with writing prose is a good one for "programming" as you do it in school where you are often crafting relatively small pieces of code and then calling them done, but is less applicable for "software engineering" where code lives a long time.