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

191–200 of 346 posts

Re: The Case for Slow Programming

#191

Post by robert_tweed »

Argorak wrote: post #45
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 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…

I like this word, we should adopt it. It says a lot about the German mindset that they have a word for this.

I don't think English has any equivalent (but it's a big language so I wouldn't be surprised to find out I'm wrong). We do have a very similar and pretty common idiom though: "slowly-but-surely", often used in the phrase "slowly but surely wins the race". This of course comes from The Hare and the Tortoise in Aesop's Fables.

Another analogy that works in programming terms is comparing the speed of a container ship to the speed of a Ferrari. One of them zips about a lot and goes round corners really fast. The other one takes a while to load up and takes an hour to turn, but it will shift a hell of a lot more cargo, a much greater distance, in the same time.

There's a place for both and the most important thing is knowing the difference; not sticking to one or the other dogmatically.

Re: The Case for Slow Programming

#192

Post by dang »

wslh wrote: post #63

I posted the same article 1 day ago... but used the https address... https://news.ycombinator.com/item?id=8678439

The dupe detector is left porous on purpose to allow good stories multiple cracks at the bat. A small number of reposts is ok.

It's true that who ends up getting the karma on a multiply-posted story is just a roll of the dice. On the other hand, you can stack your long-run odds as high as you want by submitting more and better stories. So it tends to even out in the end.

Re: The Case for Slow Programming

#193

Post by Joeri »

wmt wrote: post #179
rumcajz wrote: post #175

Earlier quoted context omitted.

Programmers are craftsmen. They need vocational schools. Academia is not up to the job.

That's actually the problem! Many current engineering disciples were before handled by craftsmen until scientific principles were applied to it, making it engineering. There have been very few scientific studies about the basics of building software, like how much unit tests really affects the bug density, and those few studies go often unnoticed when teaching future software engineers. It would require a major effor…

It's not just that not a lot of science is applied to the craft of programming. It is that many programmers are actively hostile to the concept. For example, the rules of programmers.se forbid asking for statistics. So if you want to know objective facts about the craft of programming, you're forbidden from asking for it on the most popular forum about that craft. When I asked why this rule was in place, it became apparent that the only real reason was an irrational dislike of statistics. With that kind of attitude our craft will never become an engineering discipline..

Re: The Case for Slow Programming

#194

Post by Floegipoky »

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…

Unfortunately, the process of building houses can't be compared to building software. Houses don't get bolted sideways onto scyscrapers 5 years after they're built, or suddenly need to accommodate multiple order of magnitude more people than they were originally built to hold. These are regular occurrences in the software world.

You are right that most people that come out of university are woefully unprepared to design software systems. However, that doesn't change the fact that what ends up being the "best" design in the end is rarely apparent (or appropriate) in the initial planning stages of a software project. Requirements change, and the architecture needs to adapt with them. These architectural changes do have a very real cost. The tough sell is trying to show management that the alternative creates technical debt that will strangle the project if it isn't addressed, and that the longer the refactoring is deferred, the more expensive it will be.

Re: The Case for Slow Programming

#195

Post by hvidgaard »

jodrellblank wrote: post #181
lectrick wrote: post #128

Earlier quoted context omitted.

It is the MOST trivial thing to measure performance in a Go game. It is the LEAST trivial thing to measure the "code quality"/"unit of time" metric in a programmer. For example, you might bang out an implementation that looks fine, but 1 guy will say "that will become unmaintainable in 1 year" or "that will be a problem if we ever switch databases" or whatever and sure enough, a year later, the team has to do that...…

"that will become unmaintainable in 1 year" or "that will be a problem if we ever switch databases" or whatever and sure enough, a year later, the team has to do that... and that 1 guy was fucking RIGHT. And sometimes YAGNI, we'll cross that bridge when we come to it, nice problem to have, good enough is good enough, do the simplest thing that could possibly work, premature optimization, perfect is the enemy of good,…

That is a perfect mindset to have to the problem of the type "that will be a problem if we ever switch databases". However, "that will become unmaintainable in 1 year" is a "bridge" you want to cross sooner rather than later. If you have a deadline to meet, fine, but come back and fix it asap if the software is something that needs to be maintained. I really cannot explain it well, it's just something most developers realize after a while when they've had to maintain an old codebase.

They key point however is, that one guys insight shouldn't be ignored. You can take the words of wisdom and proceed to not do anything about it, but at least you know the cost down the road. All experienced managers I know personally, know the cost of umaintainable software and are more than willing to do something about it if ressources allow it. They need to, otherwise it's their ass that is in the line of fire when it cost a factor 10 to implement a new feature and bugs creep up at the customer time after time, even though they spend a factor 10 more on QA.

Re: The Case for Slow Programming

#196

Post by tuhdo »

math0ne wrote: post #104
pzxc wrote: post #10

I recently disregarded the competence of a coworker (who is in a programmer position) because I took a class with them and saw that they could not type. They were hunting and pecking. (This guy is 50 years old so has had plenty of time to learn) Is that wrong? Does being bad at typing force you to be more thoughtful and actually make you a better programmer? Or does it just mean it takes you longer? My thinking is th…

I see no correlation between typing fast and being a good programmer. I mean how much do you even have to type to program, if I produce a page of good code in a day, thats a good day, and it doesn't take long to type.

There's no correlation but at least it makes you more productive. Like using an IDE or good editor does not make you a good programmer, but it could improve your productivity in the right situations. For example, I don't want to waste a lot of time hunt-and-pecking emails or IM. Touch typing helps.

Re: The Case for Slow Programming

#197

Post by tuhdo »

kenrikm wrote: post #38
pzxc wrote: post #10

I recently disregarded the competence of a coworker (who is in a programmer position) because I took a class with them and saw that they could not type. They were hunting and pecking. (This guy is 50 years old so has had plenty of time to learn) Is that wrong? Does being bad at typing force you to be more thoughtful and actually make you a better programmer? Or does it just mean it takes you longer? My thinking is th…

I would say it's wrong, typing faster will not produce better software. Most of the time involved in writing software is not actually writing it. You may type 3x faster but if he is 5x faster at coming up with a quality solution then your gains will be lost.

Think it the other way around: if someone can come up with a solution 5x fater than you and also type 3x faster than you, then how long you are going to catch up with him.

Re: The Case for Slow Programming

#198

Post by sssssss »

wmt wrote: post #179
rumcajz wrote: post #175

Earlier quoted context omitted.

Programmers are craftsmen. They need vocational schools. Academia is not up to the job.

That's actually the problem! Many current engineering disciples were before handled by craftsmen until scientific principles were applied to it, making it engineering. There have been very few scientific studies about the basics of building software, like how much unit tests really affects the bug density, and those few studies go often unnoticed when teaching future software engineers. It would require a major effor…

Maybe that future isn't too far away! Have you checked out Code Complete? My university used it as a textbook for a Software Engineering course. To borrow your example, it cites multiple studies about the effectiveness of unit testing on errors, as well as many other software engineering topics.

Re: The Case for Slow Programming

#199

Post by vladd »

Argorak wrote: post #45
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 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…

"swift" might be a close translation.

Re: The Case for Slow Programming

#200

Post by mattlutze »

barking wrote: post #100
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…

Zügig is just so..Germanic! It's exactly how I imagine the stereotype of German efficiency. In the anglo-saxon world we pride ourselves on how many hours we work. In Germany they work fewer hours and produce more and of better quality. At least that's my impression.

Fewer trips to the coffee pot, water cooler or smoker's lounge and a lot of the folks we know would be more productive, too.

A lot of the studies on it I've seen come down to "work time is for work, free time is for not working" and respecting that.

Post reply on HN