Hacker News Reader

Comment by einhverfr | Hacker News Reader

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 didn't get invited to face to face because I "took my time" with their puzzles. My response was that my first drafts were faulty, and that I preferred to program slowly because I could deliver more code, faster, and better by taking my time with it. In the end, their loss.

Deliberation is important. That often means slower apparent progress but faster progress overall.

View on HN

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.

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.

This is also why I don't think moving faster is almost always better. There's a certain point at which moving faster slows you down.

A better way of saying it might be "optimize your progress over the next 10 years, not over the next week."

I think there is a false choice usually presented between agile, move fast and break things, vs old waterfall approach. I don't think waterfall is the right alternative. The waterfall approach is really difficult to get right because to some extent it insulates design from coding. The integration of these two is something that agile gets right.

But what agile gets wrong is in de-emphasizing design too much. Design is important, and it is important regarding long-term progress. And if you don't design, you will pay for it a hundred times over. But the best design is where technology is designed bottom-up and UX is designed top-down. Done right, this integrates design into coding but it also emphasizes design and code contracts.

Reply on news.ycombinator.com