Going Fast Slowly
varnish-cache.org
Going Fast Slowly
1–10 of 77 posts
Re: Going Fast Slowly
#2From 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.
Re: Going Fast Slowly
#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.
Re: Going Fast Slowly
#4Footnote 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. :)
Re: Going Fast Slowly
#5Footnote 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 co…
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.
Re: Going Fast Slowly
#6From 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/
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?
Re: Going Fast Slowly
#7“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.
Lovely parable, I shall definitely use this expression with clients --
Re: Going Fast Slowly
#8Footnote 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 co…
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.
Interesting! Do have a link to an example?
Re: Going Fast Slowly
#9From 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 something to be excised, why do complex overengineered systems still prevail despite all this?
Re: Going Fast Slowly
#10From 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…
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.