6 ms·

Going Fast Slowly

137 points by mro 11y ago

CyberDildonics 11y ago
Is this is pinnacle of vapid blog spam headlines?
- deleted 11y ago
  [deleted]
bluedino 11y ago
>> Varnish has been in existence for 10 years, so that's 15K lines per year. 200 workdays a year makes that 75 lines a day. 7.5 hours of work per day gives 10 lines per hour. You can't really say that, though. Let's roll back the clock to when the project was new and say, only 10k lines of code. Maybe that first 10k was written in a month. Fleshing things out, then adding features like crazy. Coding in a euphoric state. Once you've reached a certain amount of code, you're doing maintenance. Fixing bugs. Re-factoring code. I can see 10 lines of code per day. I notice that in my own projects. I might write a few thousand lines in a week and then as time goes on, I write a few hundred, then a few tens, then maybe just a couple edits.
- andrewchambers 11y ago
  > Coding in a euphoric state. You must be fun to code with.
- taneq 11y ago
  Exactly. One of my past jobs was maintaining a mature codebase that had been under incremental development for over a decade. Most of the bug fixes I made involved anywhere from 2 hours to 2 days of investigation, usually followed by a one or two line change.
kazinator 11y ago
Slovak proverb: "ponáhľaj sa pomaly" -- Be not hasty, when you hurry.
- titanomachy 11y ago
  English has "more haste, less speed" which I think carries the same message.
  - adamtj 11y ago
    I'm told that the US military uses the phrase "Slow is smooth, smooth is fast."
  - kazinator 11y ago
    What I don't understand is why the most literal translation into English, which is equally succinct, doesn't "work" somehow. Namely the translation: "hurry slowly". It's just so awkward. Yet the grammar isn't bad; there is nothing wrong with "walk slowly" or "eat slowly". "Ponáhľaj sa pomaly" is perfectly euphonic to the Slovak ear, while "hurry slowly" seems clumsy somehow. We need to make it more sophisticated somehow, like "make slow haste", or "slow haste makes faster" or whatever. What is the reason ... I suppose; if everyone said "hurry slowly!" it might wear into usage.
- gandalfu 11y ago
  Spanish: visteme despacio que tengo prisa Or: visteme despacio que ando apurado
  - mixedCase 11y ago
    Or, in more rioplatense fashion: "Si corrés te cagás en los pantalones"
- schoen 11y ago
  It also exists in classical Latin and Greek: https://en.wikipedia.org/wiki/Festina_lente https://en.wikipedia.org/wiki/Festina_lente
bronson 11y ago
"I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." Good quote. Took me until my 30s before I started realizing this myself. Seems obvious in retrospect.
- javier2 11y ago
  I'm only one year out of uni and I figured this too. Lines of code are features and state that will increase the cost of other new features. So adding lines is a cost. The hard part is figuring out what lines of code (features) to add, do them well, and which ones you should not even make.
- haberman 11y ago
  “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” -- Bill Gates
  - yxlx 11y ago
    Also relevant: http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...
- GolfyMcG 11y ago
  A practice we've implemented to manage this is tagging pull requests that have anything over 250 added (green) lines of code. Before anyone is willing to give you a code review, you have to justify why such a pull request requires so many lines, break it into multiple pull requests, or refactor your code. Often times, it makes review easier because the PR's are smaller and enforces a simple baseline that tells the programmer, your code is too big!
  - Joeri 11y ago
    Maybe all diff views should show added lines in red and removed lines in green. If anything, it would help create awareness of the need for more compact systems.
kazinator 11y ago
Looking at the static picture is somewhat misleading. The lines of code you see in the current baseline snapshots are not all the lines that were ever written for that project. A fairly large and extensive commit affecting many lines can have a small impact on the absolute number of lines (which can even shrink). We change as well as delete existing lines, not only add new ones. The lines which are replaced by new lines should be regarded as deleted lines, and so the figure of how many lines there are now should be supplemented with how many lines were deleted since the beginning of the project: how many additional lines of code exist in the repo's history, which no longer appear in the current baseline. The invisible lines that disappeared in the history are the underpinning for the current lines; they enabled the new lines to be figured out, which took work. Someone had to write each line, and it has to be counted in the LOC output. It is not entirely clear cut. If you make a trivial change in some existing line, it's not the same thing as a brand new line. Yet, according to the line-based diff tools, it looks like a deletion and addition of an entire line. Minus this, plus that.
_snydly 11y ago
>> And eventually I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided. Maybe I'm a bit odd, but I got into programming with code golf, using lots of J, K, and others. So my growth has been the opposite. It was just last year that I realized it's okay (and maybe necessary?) for other people to read/understand my scripts.
- lomnakkus 11y ago
  > It was just last year that I realized it's okay (and maybe necessary?) for other people to read/understand my scripts. Have you never found yourself in the position of not being able to read/understand your own code/scripts? (Though, I guess if it's so compact as K/J and very in-grained, I guess it might be possible to get the overview pretty quickly?) Just FWIW, I'm in the position that other people definitely need to read/understand my code/scripts. After running git-blame I sometimes really hate past-me.
- siscia 11y ago
  Even if slightly correlated I believe you are talking about a different issues and scale. It is definitely good if other people can read your code, so you use great name convention and maybe add comments here and there, but is definitely better if people don't have to read your code because your code simply doesn't exist. If you can achieve the same result with a careful design, a lot of hours of thinking and very few hours of typing, supposing that the design and the code is understandable by your peers, your code will be "more valuable" that if you achieved the same result with a lot of code. Code is a liability is not ab asset.
  - _snydly 11y ago
    That's true, I shouldn't have compared my experience as a grad student in science to a project like Varnish. > Code is a liability is not ab asset. That's a great quote. I guess there's a sweet spot. Maybe, if only a handful of people need to be able to understand what you wrote, then the sweet spot can be skewed toward the terse end of the spectrum.
sosuke 11y ago
Using git can you also see the times a single line was changed? I bet the numbers jump quite a bit. Sure you've got a 200 line program but over time you've written 20k lines!
bracewel 11y ago
> The two CVEs against Varnish were both utterly bogus "trophy-hunter" CVEs in my opinion. (But don't take my word for it, judge for yourself.) ok > CVE-2013-4484: Varnish before 3.0.5 allows remote attackers to cause a denial of service (child-process crash and temporary caching outage) via a GET request with trailing whitespace characters and no URI. :|
FrankyHollywood 11y ago
EWD talks about lines of code as "lines spent" instead of lines produced, this is 1988 :) https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...
0x07c0 11y ago
I really like Douglas McIlroy concept of negative code. Also, the varnish source is really nice! Pen kode ;) http://programmers.stackexchange.com/questions/103807/what-is-negative-code http://programmers.stackexchange.com/questions/103807/what-i...

Going Fast Slowly

137 points by mro 11y ago

CyberDildonics 11y ago

Is this is pinnacle of vapid blog spam headlines?

deleted 11y ago
[deleted]

bluedino 11y ago

>> Varnish has been in existence for 10 years, so that's 15K lines per year. 200 workdays a year makes that 75 lines a day. 7.5 hours of work per day gives 10 lines per hour. You can't really say that, though. Let's roll back the clock to when the project was new and say, only 10k lines of code. Maybe that first 10k was written in a month. Fleshing things out, then adding features like crazy. Coding in a euphoric state. Once you've reached a certain amount of code, you're doing maintenance. Fixing bugs. Re-factoring code. I can see 10 lines of code per day. I notice that in my own projects. I might write a few thousand lines in a week and then as time goes on, I write a few hundred, then a few tens, then maybe just a couple edits.

andrewchambers 11y ago
> Coding in a euphoric state. You must be fun to code with.
taneq 11y ago
Exactly. One of my past jobs was maintaining a mature codebase that had been under incremental development for over a decade. Most of the bug fixes I made involved anywhere from 2 hours to 2 days of investigation, usually followed by a one or two line change.

kazinator 11y ago

Slovak proverb: "ponáhľaj sa pomaly" -- Be not hasty, when you hurry.

titanomachy 11y ago
English has "more haste, less speed" which I think carries the same message.
- adamtj 11y ago
  I'm told that the US military uses the phrase "Slow is smooth, smooth is fast."
- kazinator 11y ago
  What I don't understand is why the most literal translation into English, which is equally succinct, doesn't "work" somehow. Namely the translation: "hurry slowly". It's just so awkward. Yet the grammar isn't bad; there is nothing wrong with "walk slowly" or "eat slowly". "Ponáhľaj sa pomaly" is perfectly euphonic to the Slovak ear, while "hurry slowly" seems clumsy somehow. We need to make it more sophisticated somehow, like "make slow haste", or "slow haste makes faster" or whatever. What is the reason ... I suppose; if everyone said "hurry slowly!" it might wear into usage.
gandalfu 11y ago
Spanish: visteme despacio que tengo prisa Or: visteme despacio que ando apurado
- mixedCase 11y ago
  Or, in more rioplatense fashion: "Si corrés te cagás en los pantalones"
schoen 11y ago
It also exists in classical Latin and Greek: https://en.wikipedia.org/wiki/Festina_lente https://en.wikipedia.org/wiki/Festina_lente

bronson 11y ago

"I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." Good quote. Took me until my 30s before I started realizing this myself. Seems obvious in retrospect.

javier2 11y ago
I'm only one year out of uni and I figured this too. Lines of code are features and state that will increase the cost of other new features. So adding lines is a cost. The hard part is figuring out what lines of code (features) to add, do them well, and which ones you should not even make.
haberman 11y ago
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” -- Bill Gates
- yxlx 11y ago
  Also relevant: http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...
GolfyMcG 11y ago
A practice we've implemented to manage this is tagging pull requests that have anything over 250 added (green) lines of code. Before anyone is willing to give you a code review, you have to justify why such a pull request requires so many lines, break it into multiple pull requests, or refactor your code. Often times, it makes review easier because the PR's are smaller and enforces a simple baseline that tells the programmer, your code is too big!
- Joeri 11y ago
  Maybe all diff views should show added lines in red and removed lines in green. If anything, it would help create awareness of the need for more compact systems.

kazinator 11y ago

Looking at the static picture is somewhat misleading. The lines of code you see in the current baseline snapshots are not all the lines that were ever written for that project. A fairly large and extensive commit affecting many lines can have a small impact on the absolute number of lines (which can even shrink). We change as well as delete existing lines, not only add new ones. The lines which are replaced by new lines should be regarded as deleted lines, and so the figure of how many lines there are now should be supplemented with how many lines were deleted since the beginning of the project: how many additional lines of code exist in the repo's history, which no longer appear in the current baseline. The invisible lines that disappeared in the history are the underpinning for the current lines; they enabled the new lines to be figured out, which took work. Someone had to write each line, and it has to be counted in the LOC output. It is not entirely clear cut. If you make a trivial change in some existing line, it's not the same thing as a brand new line. Yet, according to the line-based diff tools, it looks like a deletion and addition of an entire line. Minus this, plus that.

_snydly 11y ago

>> And eventually I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided. Maybe I'm a bit odd, but I got into programming with code golf, using lots of J, K, and others. So my growth has been the opposite. It was just last year that I realized it's okay (and maybe necessary?) for other people to read/understand my scripts.

lomnakkus 11y ago
> It was just last year that I realized it's okay (and maybe necessary?) for other people to read/understand my scripts. Have you never found yourself in the position of not being able to read/understand your own code/scripts? (Though, I guess if it's so compact as K/J and very in-grained, I guess it might be possible to get the overview pretty quickly?) Just FWIW, I'm in the position that other people definitely need to read/understand my code/scripts. After running git-blame I sometimes really hate past-me.
siscia 11y ago
Even if slightly correlated I believe you are talking about a different issues and scale. It is definitely good if other people can read your code, so you use great name convention and maybe add comments here and there, but is definitely better if people don't have to read your code because your code simply doesn't exist. If you can achieve the same result with a careful design, a lot of hours of thinking and very few hours of typing, supposing that the design and the code is understandable by your peers, your code will be "more valuable" that if you achieved the same result with a lot of code. Code is a liability is not ab asset.
- _snydly 11y ago
  That's true, I shouldn't have compared my experience as a grad student in science to a project like Varnish. > Code is a liability is not ab asset. That's a great quote. I guess there's a sweet spot. Maybe, if only a handful of people need to be able to understand what you wrote, then the sweet spot can be skewed toward the terse end of the spectrum.

sosuke 11y ago

Using git can you also see the times a single line was changed? I bet the numbers jump quite a bit. Sure you've got a 200 line program but over time you've written 20k lines!

bracewel 11y ago

> The two CVEs against Varnish were both utterly bogus "trophy-hunter" CVEs in my opinion. (But don't take my word for it, judge for yourself.) ok > CVE-2013-4484: Varnish before 3.0.5 allows remote attackers to cause a denial of service (child-process crash and temporary caching outage) via a GET request with trailing whitespace characters and no URI. :|

FrankyHollywood 11y ago

EWD talks about lines of code as "lines spent" instead of lines produced, this is 1988 :) https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...

0x07c0 11y ago

I really like Douglas McIlroy concept of negative code. Also, the varnish source is really nice! Pen kode ;) http://programmers.stackexchange.com/questions/103807/what-is-negative-code http://programmers.stackexchange.com/questions/103807/what-i...