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

181–190 of 346 posts

Re: The Case for Slow Programming

#181

Post by jodrellblank »

lectrick wrote: post #128
hasenj wrote: post #35

Earlier quoted context omitted.

I think we can learn from some other (not-so-obviously-related) disciplines. The game of go[0] has a ranking system where players progress from 30kyu (complete beginner) to 1kyu, then 1dan to 9dan (very strong). [0]: http://en.wikipedia.org/wiki/Go_ranks_and_ratings It's mostly statistical and based around comparing your skill level to other players. While a 7kyu level is not necessarily that well defined, and might…

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, grass is always greener somewhere else, better a bird in the hand than two in the bush, he's right but it's still not worth the cost right now, etc.

Re: The Case for Slow Programming

#182

Post by diltonm »

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…

>> "slow" is going to be self-defeating nomenclature

It's pointed, poignant and accurate as well as precise; self-defeating it is not.

Re: The Case for Slow Programming

#183

Post by diltonm »

err4nt wrote: post #127

> My wife often comes out into the yard and asks me: “are you coding?” Often my answer is “yes”. I think I need this quote in my kitchen! My girlfriend often pounces be with the accusation "YOU'RE NOT WORKING" if she sees me out of my chair moving around, doing mindless house chores or half-vacantly tossing a cat toy around the house, or running errands, but the reality of _design_ is that it happens all day. And whe…

I suspect she knows when you have that stare like you're solving a puzzle while playing with the cat's toy.

Re: The Case for Slow Programming

#184

Post by agumonkey »

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 to tell that "vitesse" (noun), French for speed, comes from "viste" (adj.) and latin "vistus", rooted in vista, to see. The only way to go fast is to see, to know; and for that, one often needs to go slow.

As said below Latin has it in festina lente -- "Make haste slowly."

Re: The Case for Slow Programming

#185

Post by realrocker »

Only few businesses want a well-crafted software. Today's startups are endeavors of treasure hunts. You build a ship just good enough to hit the island. If it doesn't work out(which in all probability it won't) you dump the ship. If it does, you still dump the ship. There is a element of expected failure in the current enterprise of writing software which calls for and pushes people to knowingly write bad fast software. As the author says it will be faster to write slowly if the goal is to write good software. But the goal is rarely that.

Re: The Case for Slow Programming

#186

Post by diltonm »

beat wrote: post #64

"There's never time to do it right, but there's always time to do it over". This reminds me of something I've been saying for a while. I'm a practitioner of TDD - Test Driven Development , not Test Driven Design. I like test-first coding not because it's faster, as many proponents claim, but because it's more comfortable and thoughtful. It forces me to slow down and think about what I'm actually doing. I don't think…

>> But good design is absolutely not an emergent property of the process of coding!

>> Good design is always a matter of compromises.

You need to have coded something to have shined the flashlight into the darkness so you can put a few dots on the wall and start envisioning a path. I have small scrap projects to let me shine the light and see what reflects back.

Re: The Case for Slow Programming

#187

Post by jwmerrill »

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…

> There have been very few scientific studies about the basics of building software...

There hasn't been a lot of great quantitative scientific study on how to productively do science either. Academic science is a craft, and is more or less learned through apprenticeships.

I'm trained as a physicist, and I'm certainly a fan of quantitative scientific methods, but I think it's important to realize that there are some areas where quantitative science is effective and rewards the required work well, and other areas where it is largely an ineffective waste of time.

I suspect trying to quantitatively study things like "how much unit tests really affects the bug density" is one of these cases with a poor reward to effort ratio.

There's a danger in trying to apply quantitative science to complex phenomena, when many or most relevant factors are actually uncontrolled and unmeasured. Once you have a number--any number--the tendency is to fetishize it at the expense of broader thinking. Make no mistake: quantitative measurements of the behavior of people performing complicated tasks do not carry the same epistemological force as quantitative measurements of the magnetic dipole moment of the electron.

Scientists themselves more typically try to understand their own craft through case studies and "professional wisdom" passed down from practicing experts to apprentices. Software developers would probably do well to (continue to) do the same.

Re: The Case for Slow Programming

#188

Post by sysk »

woah wrote: post #141
NateDad wrote: post #58

Earlier quoted context omitted.

Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.

I found go to be quite cumbersome in comparison to npm. Magic folders in the filesystem and such. With node you never have to do more than npm install and everything is ready.

npm (and the CommonJS module system) is the #1 reason I use Node.js. I don't care if Javascript is ugly, npm totally makes up for it. I don't get why most module systems implicitly import symbols in the scope (Python, Ruby) or worse, those that pollute the global scope (PHP).

Brew (Ruby) is not that bad but Python's package ecosystem is a complete mess (distutils, setuptools, pip, etc.). Cabal (Haskell) is pretty good too in comparison to C/C++ (installing dependencies usually involves following instructions in a README file, that is, if there are available instructions for your OS). I haven't tried Go.

I believe the language of the future will be built around, and win mainly because of, its package system/ecosystem.

Re: The Case for Slow Programming

#189

Post by [deleted] »

woah wrote: post #141
NateDad wrote: post #58

Earlier quoted context omitted.

Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.

I found go to be quite cumbersome in comparison to npm. Magic folders in the filesystem and such. With node you never have to do more than npm install and everything is ready.

[deleted]

Re: The Case for Slow Programming

#190

Post by eropple »

4ydx wrote: post #123
cesarbs wrote: post #21

> Fast programmers build hacky tools to get around the hacky tools that they built to get around the hacky tools that they built to help them code. This resonates so much with me. Sometimes I worry that I'm falling behind on keeping up with technology, but whenever I try to learn something new it seems like I have to install a package manager, then another package manager inside the first one, then pull a million oth…

This is why something like golang is appealing. Simple simple and more simple.

Simplicity for simplicity's sake isn't a virtue. I often feel that Go chooses that path ideologically, whereas real world use cases should have more innings (yes, it's the generics and shitty type system thing again, I'm not expecting us to agree, I'm just pointing it out).

To that end, Go doesn't work for me. I use a fairly straightforward stack atop the JVM because I can hold the whole thing in my head (nothing in either Dropwizard or Play is deep magic) and have the expressiveness in Scala to be clear with my code.

Post reply on HN