[dancesdrunk]

It is decent advice but to be taken with a grain of salt - I've worked with developers who just dive in to the project, no plan in their head and just figuring out as they go along. What you're left with is a mess of code, hacks and workarounds - it works, definitely does, but maintaining or extending it is a nightmare.

On the other hand you have projects with incredibly detailed architectures all mapped out, way too much time discussing / planning / envisioning what to build, when to build it and how best to go about it. Not a single one I can think of actually followed the plan (you will always get kinks in the road), and as such these things are always over due and over budget.

I guess it's more about finding a balance with what works - perhaps keep an end goal in sight; with a simplistic high level overview of the project/feature, thus giving you the freedom to move around any problems that may arise, but also not tying you down to a detailed plan / architecture that almost certainly will need changing. Iterate fast, stay flexible(?)

But one thing I definitely agree with - and that's to get started immediately; whether that's to plan or to code - just start. It will always take longer than you think, and that last 10% is equivalent to first 90%, if not more.

[bru]

I think you're right, but I 100% reject this article. Maybe it is good advice for small- or middle-scale products, apps., etc., but it will never hold for a project whose goal is to make a global impact.

I'm actually thinking about Fabrice Bellard, who was featured in a article that was met with success here two months ago[1].

> Bellard made it seem natural to pull together his mathematical insight, broad experience at instruction-level coding, and careful engineering to advance the field this way

When you look at his achievements[2], I have trouble finding one that would have succeeded with OP's "advice". Between an app for coffee-lovers and QEMU, I think the careful thinking and engineering crushes the hype of "let's do it". Sure it sounds good, but that is not the way you will achieve something meaningful.

I may sound like an ass while it is not my goal, but

- I'm kind of surprised to see the success of this article (50 votes for 2 hours) given the low level and amount of content it offers

- I distrust analogies, and this gamma-correction one is definitely unsound (not to say dumb)

1: https://news.ycombinator.com/item?id=5187585

2: http://bellard.org/

[coldtea]

>When you look at his achievements[2], I have trouble finding one that would have succeeded with OP's "advice". Between an app for coffee-lovers and QEMU, I think the careful thinking and engineering crushes the hype of "let's do it". Sure it sounds good, but that is not the way you will achieve something meaningful.

I think both you and the parent got the wrong impression.

The article is not saying "just start coding -- and skip planning and engineering".

He says "just start working hard on the problem from day one, INCLUDING the planning and engineering parts -- instead of leaving it for later, or doing only low hanging fruits in the beginning".

"Start working hard early on != just start with coding immediately".

>- I distrust analogies, and this gamma-correction one is definitely unsound (not to say dumb)

Nothing unsound or dumb about it. It's just that he could reduce it to the curve shown --taken to mean project completion--, without mentioning gamma at all.

The curve is the important part of the analogy, not gamma.

[jaredsohn]

I don't think this is stating that (or what other responses to the parent say). Rather it is saying, figure out what the biggest risk is and try to address that first. Often for startups this will be on the business side (i.e. are you building something people want? Is the market big enough? etc.). But if what you're building requires complex engineering, requires that an API you're unfamiliar with works a certain way, requires that certain data is available to you, etc. it is helpful to also investigate these things early on so that you can be more confident of your project's feasibility and can estimate better.

[Kesty]

I think the best advice is not that you should start working right now, but that you should plan that the last 20% of your project is the one that will take most of the time.