10 ms·

Going Fast Slowly

263 points by chatmasta 7y ago

pdonis 7y ago
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/ http://plasmasturm.org/log/linesspent/
- draw_down 7y ago
  Dijkstra wrote that in 1988. Things change. The prevailing wisdom changes over time. Is anybody really proudly counting lines of code at this late date? Is there anyone out there who doesn't love an all-red diff? Is there anyone who really thinks the prolix version of a function is better than the concise one, all else equal? Who is getting paid by line of code, or has to meet a a quota of LOC?
  - jacquesm 7y ago
    The hell it does. Dijkstra's words are as important, if not even more important than when they were first written. The whole problem is that we keep re-inventing the wheel and all associated problems over and over again. We never put the lessons learned the hard way to practice in the long run. New generation -> rinse, repeat.
    - draw_down 7y ago
      I get that you have axes to grind, but that all doesn’t actually have anything to do with what I was talking about, which is essentially that nobody thinks “lots of lines of code” is a good thing anymore. I work in a startup full of twentysomethings. None of them have read “Mythical Man Month” but they all know the bit about how adding engineers to a late project makes it later. It takes time, but these things find their way into the conventional wisdom. It’s not 1988 anymore. Not everything changes, but some things do. Or do you think we all still need to be reminded that “goto” is bad and we shouldn’t use it?
      - jacquesm 7y ago
        Consider that your personal experience is no match for what we have encountered in about 140 tech reviews of companies in various industries. I'm super happy to hear that you and your crew are clued in and doing well, and that this is all 'old hat' to you. Even so, there are lots of other companies out there, some older, some newer, both large and small in regulated industries, e-commerce and so on who could very well use some of the common sense that pervades you and your team. It's definitely not 1988 anymore. Contrary to popular wisdom the programmers from back then usually were clued in, rather than that they went to javascript bootcamp and started churning out reams of low quality code. Plenty of the software from back then is still around today. The Mythical Man Month writes about a team of reasonably competent professionals and the pitfalls they encounter, not about a bunch of clueless newbies. That adding engineers to a late project makes it later is now an established fact, you would hope. And yet, not a month goes by without encountering exactly that proposition. So yes, maybe we do need that periodical reminder that 'goto' is bad and that we shouldn't use it too, fortunately the number of languages that support that construct is dwindling, and in those cases where it is used it is hidden quite well without the nasty side effects that an uncontrolled jump into them middle of a bunch of conditionals could cause.
- lucideer 7y ago
  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 something to be excised, why do complex overengineered systems still prevail despite all this?
  - edmundsauto 7y ago
    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).
    - swsieber 7y ago
      Oh, I love deleting code. I'm just scared of Chesterton's fence.
  - mathgladiator 7y ago
    I can answer from experience. The reason is that generally people can find success by doing one or two things at a time, and then polish them through testing and bug reports. This often means that the wrong things are done for the right reasons, and the debt gets bigger and the value of the system increases. This makes big rewrites really hard. This locks in the complexity, and inertia makes change expensive. I experienced this when I built a tcp socket over a request response library, and the reason was to capture the investments made in the library and suffer the pain of building tcp. This made the code complex, but it was reasonable to sell to stakeholders and achieve success on. Now, I wanted to just use a socket, but this took 1.5 years to do by slowly iterating on the right value proposition. I'm a big fan of slow massive rewrites, but it requires consistent and solid leadership to pull off.
  - bovermyer 7y ago
    Because technical beauty is not the only metric measured by businesses.
- haberman 7y ago
  There's also this from Bill Gates: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
  - quickthrower2 7y ago
    /** I'd agree that counting the occurrences of 0x0a can be misleading */
    - kube-system 7y ago
      Of course that would be misleading! ...because Bill Gates would count “0x0d 0x0a” instead. :)
- 0xCMP 7y ago
  I like lines-spent as a measure, but I wish I could figure out a hybrid measure which didn't hurt lines which confirm/narrow the state space (such as the "unnecessary asserts to show programmer intent"). Somehow being able to distinguish this would help avoid insanely complicated code (of which usually can be much, much simpler), but doesn't encourage anyone to literally ignore all error checking and do everything as some kind of chained-single-line-expression abomination [1]. [1] Something I often see in functional JS and regular python from time to time.
- bch 7y ago
  Or Bill Gates - “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
- emmelaich 7y ago
  all code is debt all code is investment only time will tell
- intenseagile 7y ago
  Any line of code you write is a line of code you have to maintain and support.
jchook 7y ago
“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.
- artsyca 7y ago
  Lovely parable, I shall definitely use this expression with clients --
- tunesmith 7y ago
  Or from my mom: "The hurrieder I go, the behinder I get!" EDIT: Apparently my mom is Lewis Carroll.
- iamaelephant 7y ago
  In motorcycle racing there's the phrase, "a fast rider has slow hands".
- 2rsf 7y ago
  unfortunately this does not hold up to reality, in many cases building the right stuff from the beginning is either too long, and you will be late to the market, or simply impossible since you don't have enough information from customers using the product. Among the many wrong reasons to the Agile way of working being able to change and adapt to reality is a valid and important one. I don't know which army are you referring to, but my army reverted to heavy bombing if smooth haven't worked.
haasted 7y ago
Footnote 6 is interesting: “I prefer asserts over comments for this, since the compiler can also see them. The good news is, the compiler can also see that they don't do anything so a lot fewer are present in the binary program. Interestingly, a couple of them allows the compiler to optimize much harder. No, I won't tell you which those are.” I appreciate the pattern of having “comments” that are equally useful to compiler and reader. And I’m impressed that some compilers actually use them to optimise the output. And I’m slightly baffled that the examples of these are apparently a secret. :)
- FreeFull 7y ago
  In Rust, an assert can turn multiple bounds checks on array indexing into just a single bounds check. Maybe it's something along those lines here too.
  - drewm1980 7y ago
    Interesting! Do have a link to an example?
    - FreeFull 7y ago
      Given the following code (and with optimisations on): pub fn no_assert(input: &mut [u8]) { for i in 0..10 { input[i] += input[i+1]; } } pub fn with_assert(input: &mut [u8]) { assert!(input.len() >= 11); for i in 0..10 { input[i] += input[i+1]; } } The no_assert function ends up doing a bounds check for every iteration, and the with_assert function only does a single check.
      - tudelo 7y ago
        Still that assert has to be checked at some point right? I would assume that maybe the compiler could do this optimization without having to be told.
        7y ago
zokier 7y ago
About the numbers, I feel like going through the commit diffs and counting all the + lines would be better (in some sense) metric than counting the final lines of code if we'd want some proxy for the amount of labor.
- nemo1618 7y ago
  Indeed. Reminds me of arcfide's Co-dfns compiler: >I think the first copyright on this compiler is around 2011. That's 6 years for 750 LoC. That's about 125 lines of code per year. >But that doesn't tell the whole story. If you look at the GitHub contributions that I've made, I've made 2967 of about 3000 commits to the compiler source over that time frame. In that time I've added roughly 4,062,847 lines of code to the code base, and deleted roughly 3,753,677 line of code. And there's the real story...It means that for every one of those 750 lines, I've had to examine, rework, and reject around 5400 lines of code. https://www.sacrideo.us/smaller-code-better-code/ https://www.sacrideo.us/smaller-code-better-code/
  - kardos 7y ago
    Is this [1] the code he speaks of? [1] https://github.com/Co-dfns/Co-dfns/tree/master/cmp https://github.com/Co-dfns/Co-dfns/tree/master/cmp
    - jacquesm 7y ago
      It's an APL compiler, written in another APL dialect, which is about as dense as you can get in terms of lines-of-code. APL is one of the few really high level languages.
      - jeremyjh 7y ago
        It looks like a lot of the lines of diffs are to HTML/XML files related to the certification of the code, rather than executable code. So, definitely not very dense. https://github.com/Co-dfns/Co-dfns/commit/78d0e38f8ba2e1de9f2b0e9ec22df4e1f17f4fe6 https://github.com/Co-dfns/Co-dfns/commit/78d0e38f8ba2e1de9f...
bt848 7y ago
10 LOC/h is spectacularly good over a long time period. Congratulations, from a varnish user. I recently tried to set expectations in a coding interview that was scheduled for 3 hours. I told them that was enough time to read the spec, develop a simple test case, and begin or possibly complete an implementation of part of the spec. I also told them that I wasn't interested in a shop that hired people based on their ability to dash off broken, untested code in half a day. It seems to me that this kind of coding test (especially for someone with 25 years of open-source contributions) can only lead to bad things. I'd be glad to meet people like the author who have a practical view on Brooks and LOC/h.
- josephg 7y ago
  I've been doing tech interviews professionally for a large tech interview platform that you would have heard of. We have a timed coding challenge, but code quality is something we explicitly look for. Making slow but steady process with good testing is a great signal for us too, even if they don't get very far through our challenge within the allocated time. That said, occasionally we have people who work very quickly and somehow still have great code. Thats an even better signal.
  - p1necone 7y ago
    I hope it's communicated that they're not expected to finish. If I was given a coding challenge with a time limit I would assume I was expected to finish inside the time limit and make any sacrifices that needed to be made to achieve that - including ignoring testing and hoping I just don't make too many mistakes.
    - aidenn0 7y ago
      Assuming GP is talking about what I think he is, then yes they tell you ahead of time.
- stkdump 7y ago
  Most coding interview challenges I came along are of limited complexity. I think it is important to clarify that reading, discussing the spec, writing tests a priori is something you would do in a real world coding task, but interviewers are usually more interested in the ability to discuss different approaches to solve them with their expected pros/cons, explain why some approaches won't work, prototype one out with some clean code and explain your thinking while writing the code. An experienced developer usually won't make a lot of mistakes for simple problems that require unit tests to see. If they do, the interviewer will make them aware and play the role of the testing, just to see how the candidate would react and solve the problem.
tanchoux 7y ago
Slow enough to not offer Varnish for Buster, 2 months after Debian release... ;-)
- xemdetia 7y ago
  What are you talking about that they did 'not offer Varnish for Buster?' Was there a packaging problem or more context you could add here?
  - nobodyusing 7y ago
    It looks like Debian 10 (Buster), which was released 2019-07-06 contains Varnish 6.1 instead of 6.2, which was released 2019-03-15.
    - 693471 7y ago
      6.3.0 is already out...
      - tanchoux 7y ago
        Since 2 days yes, but not for Buster.
        josephg 7y ago
        Its opensource and maintained by volunteers. If this matters to you, don't whine on HN. Write a PR.
  - tanchoux 7y ago
    Official Varnish repositorie (https://packagecloud.io/varnishcache https://packagecloud.io/varnishcache) doesn't offer any release for Buster yet. 6.3 was added since 2 days, but not for Buster yet.
jpm_sd 7y ago
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 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_Bookstore https://en.wikipedia.org/wiki/Mr._Penumbra%27s_24-Hour_Books...
nineteen999 7y ago
> 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.
- jacquesm 7y ago
  'Assert early and often'. Check your assumptions all the time, nine out of ten times that's where your bugs will hide.
  - nineteen999 7y ago
    My C programs always start as a few skeleton .h files with include guards, and a few .c files that are basically an ever growing list of asserts() on any pointer to a structure or variable, or on any value where it is expected to be within a certain range. Gradually I feed my structs and typedefs into the .h files and replace the asserts with (hopefully) working code.
kevinb7 7y ago
I wonder if this project, at least VCL compiler part of it, could've benefited from the use of a parser generator. I understand going slow, but using a parser generator would've allowed for faster development of VCL freeing up time to add more features so it isn't so hard to write for.
314 7y ago
While it is true that SLOC is not a good measure, this does not mean that no good measure uses SLOC. Much of the variance comes a lack of information about coding style and algorithmic approach. But it's not the 90s anymore. In the presence of a style guide and code reviews to ensure that the local style is being followed properly SLOC counts do become locally comparable as a reasonable measure. I'd still use the churn rate (lines added + line removed) as a rate of productivity though, over just lines added.

263 points by chatmasta 7y ago

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/ http://plasmasturm.org/log/linesspent/

draw_down 7y ago
Dijkstra wrote that in 1988. Things change. The prevailing wisdom changes over time. Is anybody really proudly counting lines of code at this late date? Is there anyone out there who doesn't love an all-red diff? Is there anyone who really thinks the prolix version of a function is better than the concise one, all else equal? Who is getting paid by line of code, or has to meet a a quota of LOC?
- jacquesm 7y ago
  The hell it does. Dijkstra's words are as important, if not even more important than when they were first written. The whole problem is that we keep re-inventing the wheel and all associated problems over and over again. We never put the lessons learned the hard way to practice in the long run. New generation -> rinse, repeat.
  - draw_down 7y ago
    I get that you have axes to grind, but that all doesn’t actually have anything to do with what I was talking about, which is essentially that nobody thinks “lots of lines of code” is a good thing anymore. I work in a startup full of twentysomethings. None of them have read “Mythical Man Month” but they all know the bit about how adding engineers to a late project makes it later. It takes time, but these things find their way into the conventional wisdom. It’s not 1988 anymore. Not everything changes, but some things do. Or do you think we all still need to be reminded that “goto” is bad and we shouldn’t use it?
    - jacquesm 7y ago
      Consider that your personal experience is no match for what we have encountered in about 140 tech reviews of companies in various industries. I'm super happy to hear that you and your crew are clued in and doing well, and that this is all 'old hat' to you. Even so, there are lots of other companies out there, some older, some newer, both large and small in regulated industries, e-commerce and so on who could very well use some of the common sense that pervades you and your team. It's definitely not 1988 anymore. Contrary to popular wisdom the programmers from back then usually were clued in, rather than that they went to javascript bootcamp and started churning out reams of low quality code. Plenty of the software from back then is still around today. The Mythical Man Month writes about a team of reasonably competent professionals and the pitfalls they encounter, not about a bunch of clueless newbies. That adding engineers to a late project makes it later is now an established fact, you would hope. And yet, not a month goes by without encountering exactly that proposition. So yes, maybe we do need that periodical reminder that 'goto' is bad and that we shouldn't use it too, fortunately the number of languages that support that construct is dwindling, and in those cases where it is used it is hidden quite well without the nasty side effects that an uncontrolled jump into them middle of a bunch of conditionals could cause.
lucideer 7y ago
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 something to be excised, why do complex overengineered systems still prevail despite all this?
- edmundsauto 7y ago
  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).
  - swsieber 7y ago
    Oh, I love deleting code. I'm just scared of Chesterton's fence.
- mathgladiator 7y ago
  I can answer from experience. The reason is that generally people can find success by doing one or two things at a time, and then polish them through testing and bug reports. This often means that the wrong things are done for the right reasons, and the debt gets bigger and the value of the system increases. This makes big rewrites really hard. This locks in the complexity, and inertia makes change expensive. I experienced this when I built a tcp socket over a request response library, and the reason was to capture the investments made in the library and suffer the pain of building tcp. This made the code complex, but it was reasonable to sell to stakeholders and achieve success on. Now, I wanted to just use a socket, but this took 1.5 years to do by slowly iterating on the right value proposition. I'm a big fan of slow massive rewrites, but it requires consistent and solid leadership to pull off.
- bovermyer 7y ago
  Because technical beauty is not the only metric measured by businesses.
haberman 7y ago
There's also this from Bill Gates: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
- quickthrower2 7y ago
  /** I'd agree that counting the occurrences of 0x0a can be misleading */
  - kube-system 7y ago
    Of course that would be misleading! ...because Bill Gates would count “0x0d 0x0a” instead. :)
0xCMP 7y ago
I like lines-spent as a measure, but I wish I could figure out a hybrid measure which didn't hurt lines which confirm/narrow the state space (such as the "unnecessary asserts to show programmer intent"). Somehow being able to distinguish this would help avoid insanely complicated code (of which usually can be much, much simpler), but doesn't encourage anyone to literally ignore all error checking and do everything as some kind of chained-single-line-expression abomination [1]. [1] Something I often see in functional JS and regular python from time to time.
bch 7y ago
Or Bill Gates - “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
emmelaich 7y ago
all code is debt all code is investment only time will tell
intenseagile 7y ago
Any line of code you write is a line of code you have to maintain and support.

jchook 7y ago

“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.

artsyca 7y ago
Lovely parable, I shall definitely use this expression with clients --
tunesmith 7y ago
Or from my mom: "The hurrieder I go, the behinder I get!" EDIT: Apparently my mom is Lewis Carroll.
iamaelephant 7y ago
In motorcycle racing there's the phrase, "a fast rider has slow hands".
2rsf 7y ago
unfortunately this does not hold up to reality, in many cases building the right stuff from the beginning is either too long, and you will be late to the market, or simply impossible since you don't have enough information from customers using the product. Among the many wrong reasons to the Agile way of working being able to change and adapt to reality is a valid and important one. I don't know which army are you referring to, but my army reverted to heavy bombing if smooth haven't worked.

haasted 7y ago

Footnote 6 is interesting: “I prefer asserts over comments for this, since the compiler can also see them. The good news is, the compiler can also see that they don't do anything so a lot fewer are present in the binary program. Interestingly, a couple of them allows the compiler to optimize much harder. No, I won't tell you which those are.” I appreciate the pattern of having “comments” that are equally useful to compiler and reader. And I’m impressed that some compilers actually use them to optimise the output. And I’m slightly baffled that the examples of these are apparently a secret. :)

FreeFull 7y ago
In Rust, an assert can turn multiple bounds checks on array indexing into just a single bounds check. Maybe it's something along those lines here too.
- drewm1980 7y ago
  Interesting! Do have a link to an example?
  - FreeFull 7y ago
    Given the following code (and with optimisations on): pub fn no_assert(input: &mut [u8]) { for i in 0..10 { input[i] += input[i+1]; } } pub fn with_assert(input: &mut [u8]) { assert!(input.len() >= 11); for i in 0..10 { input[i] += input[i+1]; } } The no_assert function ends up doing a bounds check for every iteration, and the with_assert function only does a single check.
    - tudelo 7y ago
      Still that assert has to be checked at some point right? I would assume that maybe the compiler could do this optimization without having to be told.
      - 7y ago

zokier 7y ago

About the numbers, I feel like going through the commit diffs and counting all the + lines would be better (in some sense) metric than counting the final lines of code if we'd want some proxy for the amount of labor.

nemo1618 7y ago
Indeed. Reminds me of arcfide's Co-dfns compiler: >I think the first copyright on this compiler is around 2011. That's 6 years for 750 LoC. That's about 125 lines of code per year. >But that doesn't tell the whole story. If you look at the GitHub contributions that I've made, I've made 2967 of about 3000 commits to the compiler source over that time frame. In that time I've added roughly 4,062,847 lines of code to the code base, and deleted roughly 3,753,677 line of code. And there's the real story...It means that for every one of those 750 lines, I've had to examine, rework, and reject around 5400 lines of code. https://www.sacrideo.us/smaller-code-better-code/ https://www.sacrideo.us/smaller-code-better-code/
- kardos 7y ago
  Is this [1] the code he speaks of? [1] https://github.com/Co-dfns/Co-dfns/tree/master/cmp https://github.com/Co-dfns/Co-dfns/tree/master/cmp
  - jacquesm 7y ago
    It's an APL compiler, written in another APL dialect, which is about as dense as you can get in terms of lines-of-code. APL is one of the few really high level languages.
    - jeremyjh 7y ago
      It looks like a lot of the lines of diffs are to HTML/XML files related to the certification of the code, rather than executable code. So, definitely not very dense. https://github.com/Co-dfns/Co-dfns/commit/78d0e38f8ba2e1de9f2b0e9ec22df4e1f17f4fe6 https://github.com/Co-dfns/Co-dfns/commit/78d0e38f8ba2e1de9f...

bt848 7y ago

10 LOC/h is spectacularly good over a long time period. Congratulations, from a varnish user. I recently tried to set expectations in a coding interview that was scheduled for 3 hours. I told them that was enough time to read the spec, develop a simple test case, and begin or possibly complete an implementation of part of the spec. I also told them that I wasn't interested in a shop that hired people based on their ability to dash off broken, untested code in half a day. It seems to me that this kind of coding test (especially for someone with 25 years of open-source contributions) can only lead to bad things. I'd be glad to meet people like the author who have a practical view on Brooks and LOC/h.

josephg 7y ago
I've been doing tech interviews professionally for a large tech interview platform that you would have heard of. We have a timed coding challenge, but code quality is something we explicitly look for. Making slow but steady process with good testing is a great signal for us too, even if they don't get very far through our challenge within the allocated time. That said, occasionally we have people who work very quickly and somehow still have great code. Thats an even better signal.
- p1necone 7y ago
  I hope it's communicated that they're not expected to finish. If I was given a coding challenge with a time limit I would assume I was expected to finish inside the time limit and make any sacrifices that needed to be made to achieve that - including ignoring testing and hoping I just don't make too many mistakes.
  - aidenn0 7y ago
    Assuming GP is talking about what I think he is, then yes they tell you ahead of time.
stkdump 7y ago
Most coding interview challenges I came along are of limited complexity. I think it is important to clarify that reading, discussing the spec, writing tests a priori is something you would do in a real world coding task, but interviewers are usually more interested in the ability to discuss different approaches to solve them with their expected pros/cons, explain why some approaches won't work, prototype one out with some clean code and explain your thinking while writing the code. An experienced developer usually won't make a lot of mistakes for simple problems that require unit tests to see. If they do, the interviewer will make them aware and play the role of the testing, just to see how the candidate would react and solve the problem.

tanchoux 7y ago

Slow enough to not offer Varnish for Buster, 2 months after Debian release... ;-)

xemdetia 7y ago
What are you talking about that they did 'not offer Varnish for Buster?' Was there a packaging problem or more context you could add here?
- nobodyusing 7y ago
  It looks like Debian 10 (Buster), which was released 2019-07-06 contains Varnish 6.1 instead of 6.2, which was released 2019-03-15.
  - 693471 7y ago
    6.3.0 is already out...
    - tanchoux 7y ago
      Since 2 days yes, but not for Buster.
      - josephg 7y ago
        Its opensource and maintained by volunteers. If this matters to you, don't whine on HN. Write a PR.
- tanchoux 7y ago
  Official Varnish repositorie (https://packagecloud.io/varnishcache https://packagecloud.io/varnishcache) doesn't offer any release for Buster yet. 6.3 was added since 2 days, but not for Buster yet.

jpm_sd 7y ago

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 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_Bookstore https://en.wikipedia.org/wiki/Mr._Penumbra%27s_24-Hour_Books...

nineteen999 7y ago

> 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.

jacquesm 7y ago
'Assert early and often'. Check your assumptions all the time, nine out of ten times that's where your bugs will hide.
- nineteen999 7y ago
  My C programs always start as a few skeleton .h files with include guards, and a few .c files that are basically an ever growing list of asserts() on any pointer to a structure or variable, or on any value where it is expected to be within a certain range. Gradually I feed my structs and typedefs into the .h files and replace the asserts with (hopefully) working code.

kevinb7 7y ago

I wonder if this project, at least VCL compiler part of it, could've benefited from the use of a parser generator. I understand going slow, but using a parser generator would've allowed for faster development of VCL freeing up time to add more features so it isn't so hard to write for.

314 7y ago

While it is true that SLOC is not a good measure, this does not mean that no good measure uses SLOC. Much of the variance comes a lack of information about coding style and algorithmic approach. But it's not the 90s anymore. In the presence of a style guide and code reviews to ensure that the local style is being followed properly SLOC counts do become locally comparable as a reasonable measure. I'd still use the churn rate (lines added + line removed) as a rate of productivity though, over just lines added.