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

The Case for Slow Programming

ventrellathing.wordpress.com

Post reply on HN
Print view View original

231–240 of 346 posts

Re: The Case for Slow Programming

#231

Post by fsloth »

aoakenfo wrote: post #61

A flurry of hacks tends to beat the "correctly designed" way: http://www.jwz.org/doc/worse-is-better.html

I don't think this describes a "flurry of hacks".

To me, the confrontation posed there is not between speed and quality, but which constraints affect the system design most: coherence, or overall simplicity. I would claim the "worse is better" school of design aims to lower overall complexity by cutting the corners where the added complexity to maintain design coherence does not seemingly add any value to the implementation nor the end users.

Re: The Case for Slow Programming

#232

Post by duncanawoods »

einhverfr wrote: post #145
wellpast wrote: post #22

I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…

I am not so sure. The point of "slow programming" is the same as "slow food" and "slow democracy." I think you have to see the three together. The point is to slow down, deliberate, and then do. That doesn't mean long iterations, nor does it mean deferring progress. It means ensuring solidity of the progress as you make it. I once interviewed for a job at one of the most recognized and big Perl shops in the world and…

Yep - there are benefits to a slogan being counter-intuitive because the whole point is to challenge the intuitive way of approaching a problem and making you see it anew.

In the reverse case, facebook's "move fast and break things" works because it suggests you move fast enough to dare breaking things to try an overcome the caution that holds people back from doing great things.

In this case the equivalent slogan might be "Do it right and ship it late" i.e. its so important to get it right its worth risking missing a shipping date. Practical principles, like the agile manifesto, describe a preferred trade-off rather than just naming a good attribute like swiftness, because who doesn't want the good attribute? It would be irrational.

I think this also highlights why moving faster is nearly always better even if uncomfortable for some: its a more effective way of handling uncertainty and learning faster that in most commercial environments is more important than quality. Quality in the wrong places is waste.

Re: The Case for Slow Programming

#233

Post by einhverfr »

duncanawoods wrote: post #232
einhverfr wrote: post #145

Earlier quoted context omitted.

I am not so sure. The point of "slow programming" is the same as "slow food" and "slow democracy." I think you have to see the three together. The point is to slow down, deliberate, and then do. That doesn't mean long iterations, nor does it mean deferring progress. It means ensuring solidity of the progress as you make it. I once interviewed for a job at one of the most recognized and big Perl shops in the world and…

Yep - there are benefits to a slogan being counter-intuitive because the whole point is to challenge the intuitive way of approaching a problem and making you see it anew. In the reverse case, facebook's "move fast and break things" works because it suggests you move fast enough to dare breaking things to try an overcome the caution that holds people back from doing great things. In this case the equivalent slogan mi…

I am not sure that ship it late necessarily becomes a part of slow coding. The point is to code deliberately and with quality. Once you have a production codebase, if you do things right, there's no reason you can't ship on a fixed schedule. You might ship less initially than you expected, but in the long run, you will ship more than you expect, because the delay of design pays back later.

Re: The Case for Slow Programming

#234

Post by einhverfr »

larrys wrote: post #93

"I’m Glad I’m not a Touch-Typist." Have to disagree with this 100%. A touch typist can always hunt and peck if they want to or need to for some reason (would love to have a reason for this being a benefit though). Being able to touch type helps greatly with just about everything when you are using a keyboard. Sending emails, writing letters, filling out forms, coding, the command line and so on. Not only that but it'…

I agree but the concentration that comes with slowing down thoughts is also a very valuable skill. I suggest learning to write with a quill pen, or at least a dip fountain pen.

Coincidentally many of the better coders I have known have valued dip fountain pens.....

Re: The Case for Slow Programming

#235

Post by spacecowboy_lon »

elwell wrote: post #24
wellpast wrote: post #22

I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…

But I think the main reason for choosing the word "slow" is to bring to mind its connection with the Slow Movement [0]; as the author mentioned. [0] - https://en.wikipedia.org/wiki/Slow_Movement

from what I understand the slow movement came out of the hard left in italy - and from what hhe told me the internet is still regarded as a yankee/capitalist plot based on his experiance trying to sell the idea of .coop to italian coop's

Re: The Case for Slow Programming

#236

Post by jroseattle »

IMHO....

This can be appropriate in certain scenarios. It royally sucks for other scenarios, though. Measure-twice, cut-once is a great development strategy. However, iterative-fast can have as many benefits as slow-and-steady.

Are you certain about your feature set? Must the feature be everything we can imagine when it's released for the very first time? Are there umpteen other things that also need to be addressed in the allotted amount of time? Are you sure you're not over-engineering a solution?

The biggest issue with slow-and-steady: cost and time-to-market. Of course one can argue "but cost is actually lower" and "time-to-market for a solid product will be the same or less", but (for me) that equates to any iteration having zero value along the way. And for us, that's just not true.

I'm default-wired to well-thought systems and architecturally sound operations. I would certainly like to deep-dive into our codebase and bring it to a beautiful state of robustful bliss. The only problem is -- I can't afford it right now. Maybe later, but early in our lifecycle, speed is more valuable.

Re: The Case for Slow Programming

#238

Post by klibertp »

dschiptsov wrote: post #205

> You can’t wish away Design Process. Furious activity is no substitute for understanding. Before you start to writing the code, YOU HAVE SPEND A LOT OF TIME STUDYING YOUR PROBLEM. (Brian Harvey, CS61A) If you can’t write it down in English, you can’t code it. Programs must be written for people to read, and only incidentally for machines to execute. Immortal classic.) The sooner you start to code, the longer the pro…

> In "old times", [...] being mostly scientists

Citation needed.

For every scientist involved with computers in "old times" (at least after personal computing took off) you get easily 10 hobbyists, enthusiasts who actually built stuff.

Re: The Case for Slow Programming

#239

Post by felxh »

aragot wrote: post #204
Argorak wrote: post #45

Earlier quoted context omitted.

> I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. German has a very nice word for that: "zügig". It means "speedy" as well, but goes a bit towards "stable", "steady" and "friction-free". It's the good kind of fast, which…

"Zug" means "train", "-ig" makes it an adverb like "train-ly". Can a German speaker confirm please? In English, I'd say a train has a fast & steady speed, therefore I propose the translation "steady".

Zug does mean train but it comes from ziehen (to pull) as others mentioned. So I am not sure whether zügig comes from the original meaning or from 'train'. The english cognate for Zug/ziehen is tug btw (follows the common t -> z shift in german)

Re: The Case for Slow Programming

#240

Post by tragic »

thisGuysAccount wrote: post #155
curiousHacker wrote: post #132

Earlier quoted context omitted.

Describe good architectural choices?

There are three types of "good architectural choices" The first: The ones that can be made after the original, bad ones. The second draft, which is an improvement in the first draft, in every field. The second: His (or her) own. We all know there are developers out there who think they're the greatest thing to ever write code, and that everyone else's decisions are bad. The third: The ones that really should have bee…

> As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?"

(Shuffles away sheepishly)

Post reply on HN