Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Going Fast Slowly

varnish-cache.org

Post reply on HN
Print view View original

21–30 of 77 posts

Re: Going Fast Slowly

#21

Post by edmundsauto »

lucideer wrote: post #9
pdonis wrote: post #2

From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. http://plasmasturm.org/log/linesspent/

Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…

IMO, it's due to the Action Bias. Human psychology prefers to take action rather than wait around. Making new code feels more active than deleting code (at least to me).

Re: Going Fast Slowly

#23

Post by swsieber »

edmundsauto wrote: post #21
lucideer wrote: post #9

Earlier quoted context omitted.

Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…

IMO, it's due to the Action Bias. Human psychology prefers to take action rather than wait around. Making new code feels more active than deleting code (at least to me).

Oh, I love deleting code. I'm just scared of Chesterton's fence.

Re: Going Fast Slowly

#24

Post by tunesmith »

jchook wrote: post #3

“Slow is smooth, and smooth is fast” Old military saying that I repeat often because I have relearned so many times that shortcuts cause more work (read: problems and rigidity) in the long run. Choose one: get it done right, or get it done right now.

Or from my mom: "The hurrieder I go, the behinder I get!"

EDIT: Apparently my mom is Lewis Carroll.

Re: Going Fast Slowly

#25

Post by soneca »

lucideer wrote: post #9
pdonis wrote: post #2

From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. http://plasmasturm.org/log/linesspent/

Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…

Regarding the sibling dead comment, it is not uncommon that comments are dead from start, not because they were downvoted in this thread.

I don't know, but I imagine it is one of the HN automated moderation actions, based on previous downvotes of that user comments.

There is "vouche" feature to minimize unfairness in these cases. If you do not agree that a particular comment should be dead from start, you can click on the timestamp (to go to the permanent link of the comment) and click on vouche. I do this sometimes. I did now for the mentioned comment (from draw_down ) because I agree with you that it is a valuable comment and it is not dead anymore.

Re: Going Fast Slowly

#26

Post by jpm_sd »

The strategy of "making haste slowly" dates back to the Roman empire (or earlier!), where they said "Festina lente"

https://en.wikipedia.org/wiki/Festina_lente

This was also used as a catch-phrase or motto in "Mr. Penumbra's 24-Hour Bookstore", which is a fun read, especially if you're familiar with the Silicon Valley tech scene.

https://en.wikipedia.org/wiki/Mr._Penumbra%27s_24-Hour_Books...

Re: Going Fast Slowly

#27

Post by jcelerier »

lucideer wrote: post #9
pdonis wrote: post #2

From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. http://plasmasturm.org/log/linesspent/

Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…

because in the end, people use your software for its features

Re: Going Fast Slowly

#28

Post by thaumaturgy »

lucideer wrote: post #9
pdonis wrote: post #2

From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. http://plasmasturm.org/log/linesspent/

Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…

Software-as-art has lost a lot of ground to software-as-business, and in software-as-business, somewhere up the chain there is a management-level individual who isn't really sure how to measure either progress or code quality.

There are myriad tools designed for these people though, and they all chose the simplest (and wrong) solutions to the problem: progress is SLOC added and bug reports clsoed per day.

The height of the software-as-art era was the shareware days of the late 90s. Development certainly moved a lot more slowly overall, but there also tended to be better relationships between developers and their users and developers were not yet all working for people who tried to measure their progress by the only metrics they could understand. The entire industry has been a victim of Goodhart's Law.

Re: Going Fast Slowly

#29

Post by NotATroll »

lucideer wrote: post #9
pdonis wrote: post #2

From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. http://plasmasturm.org/log/linesspent/

Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…

> why do complex overengineered systems still prevail despite all this?

Well for one, IDE's help hide a lot of the complexity by offering rapid auto-completion for even the most complex of systems.

For two, it's not something you can read and truly grasp. Complexity doesn't necessarily have an objective measurement. Even the attempts we have of measuring it, such as cyclomatic complexity, don't really tell a full story.

You could reduce a somewhat complex string manipulation down to a regex replace. But that regex replace may be far harder for someone to understand what it actually does, even if they're experienced with that particular flavor of regex.

To be blunt, 100 lines of code could be easier to understand than 25 lines that do the exact same thing. It just depends on the reader & the task at hand.

Re: Going Fast Slowly

#30

Post by nineteen999 »

> This is why Varnish is written in "pidgin C" style and lousy with asserts which don't do anything, except clarify programmer intent, and in case of mistakes, stop bad things before they get out of hand.

Today I learned a new name for my C coding style.

Post reply on HN