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/

>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.

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.

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.